Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/standards/posix/1003.0/all

Text File | 1993-07-15 | 748.8 KB | 22,705 lines

          IEEE P1003.0 Draft 14    - November 1991


            Copyright (c) 1991 by the
     Institute of Electrical and Electronics Engineers, Inc.
               345 East 47th Street
             New York, NY 10017, USA
           All rights reserved as an unpublished work.

       This is an unapproved and unpublished IEEE Standards Draft,
       subject to change.  The publication, distribution, or
       copying of this draft, as well as all derivative    works based
       on this draft, is expressly prohibited except as    set forth
       below.

       Permission is hereby granted for    IEEE Standards Committee
       participants to reproduce this document for purposes of IEEE
       standardization activities only,    and subject to the
       restrictions contained herein.

       Permission is hereby also granted for member bodies and
       technical committees of ISO and IEC to reproduce    this
       document    for purposes of    developing a national position,
       subject to the restrictions contained herein.

       Permission is hereby also granted to the    preceding entities
       to make limited copies of this document in an electronic
       form only for the stated    activities.

       The following restrictions apply    to reproducing or
       transmitting the    document in any    form:  1) all copies or
       portions    thereof    must identify the document's IEEE project
       number and draft    number,    and must be accompanied    by this
       entire notice in    a prominent location; 2) no portion of this
       document    may be redistributed in    any modified or    abridged
       form without the    prior approval of the IEEE Standards
       Department.

       Other entities seeking permission to reproduce this
       document, or any    portion    thereof, for standardization or
       other activities, must contact the IEEE Standards Department
       for the appropriate license.

       Use of information contained in this unapproved draft is    at
       your own    risk.

        IEEE Standards Department
        Copyright and Permissions
        445    Hoes Lane, P.O.    Box 1331
        Piscataway,    NJ 08855-1331, USA
        [phone]
        [phone] [FAX]



















                                                          P1003.0 Draft 14







                             STANDARDS PROJECT

                            Draft Guide to the
                      POSIX Open Systems Environment


                                  Sponsor
                 Technical Committee on Operating Systems
                       and Application Environments
                                  of the
                           IEEE Computer Society



 Abstract:  IEEE Std 1003.0-199x  presents  an  overview  of  open  system
 concepts  and  their  application.   Information  is  provided to persons
 evaluating systems on the existence  of,  and  interrelationships  among,
 application   software   standards,   with   the  objective  of  enabling
 application portability and  system  interoperability.   A  framework  is
 presented  that  identifies key information system interfaces involved in
 application portability and system  interoperability  and  describes  the
 services   offered  across  these  interfaces.   Standards  or  standards
 activities associated with the services are identified where they  exist,
 or  are  in  progress.   Gaps  are  identified  where  POSIX  Open System
 Environment  (OSE)  requirements  are  not  being  addressed   currently.
 Finally,  the OSE profile concept is discussed with examples from several
 application domains.

 Keywords:  application portability, open system  environments,  profiles,
 POSIX


                               P1003.0 / D14
                               November 1991


                         Copyright (c) 1991 by the
          Institute of Electrical and Electronics Engineers, Inc.
                           345 East 47th Street
                          New York, NY 10017, USA
                           All rights reserved.
















































 _T_h_i_s _i_s _a_n _u_n_a_p_p_r_o_v_e_d _I_E_E_E _S_t_a_n_d_a_r_d_s _D_r_a_f_t, _s_u_b_j_e_c_t _t_o _c_h_a_n_g_e. _P_e_r_m_i_s_s_i_o_n
 _i_s _h_e_r_e_b_y _g_r_a_n_t_e_d _f_o_r _I_E_E_E _S_t_a_n_d_a_r_d_s _C_o_m_m_i_t_t_e_e _p_a_r_t_i_c_i_p_a_n_t_s _t_o _r_e_p_r_o_d_u_c_e
 _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r _p_u_r_p_o_s_e_s _o_f _I_E_E_E _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _a_c_t_i_v_i_t_i_e_s. _P_e_r_m_i_s_s_i_o_n
 _i_s _a_l_s_o _g_r_a_n_t_e_d _f_o_r _m_e_m_b_e_r _b_o_d_i_e_s _a_n_d _t_e_c_h_n_i_c_a_l _c_o_m_m_i_t_t_e_e_s _o_f _I_S_O _a_n_d _I_E_C
 _t_o _r_e_p_r_o_d_u_c_e _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r _p_u_r_p_o_s_e_s _o_f _d_e_v_e_l_o_p_i_n_g _a _n_a_t_i_o_n_a_l _p_o_s_i_t_i_o_n.
     _O_t_h_e_r _e_n_t_i_t_i_e_s _s_e_e_k_i_n_g _p_e_r_m_i_s_s_i_o_n _t_o _r_e_p_r_o_d_u_c_e _t_h_i_s _d_o_c_u_m_e_n_t _f_o_r
   _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _o_r _o_t_h_e_r _a_c_t_i_v_i_t_i_e_s, _o_r _t_o _r_e_p_r_o_d_u_c_e _p_o_r_t_i_o_n_s _o_f _t_h_i_s
     _d_o_c_u_m_e_n_t _f_o_r _t_h_e_s_e _o_r _o_t_h_e_r _u_s_e_s, _m_u_s_t _c_o_n_t_a_c_t _t_h_e _I_E_E_E _S_t_a_n_d_a_r_d_s
 _D_e_p_a_r_t_m_e_n_t _f_o_r _t_h_e _a_p_p_r_o_p_r_i_a_t_e _l_i_c_e_n_s_e.  _U_s_e _o_f _i_n_f_o_r_m_a_t_i_o_n _c_o_n_t_a_i_n_e_d _i_n
                _t_h_i_s _u_n_a_p_p_r_o_v_e_d _d_r_a_f_t _i_s _a_t _y_o_u_r _o_w_n _r_i_s_k.

 IEEE Standards Department
 Copyright and Permissions
 445 Hoes Lane, P.O. Box 1331
 Piscataway, NJ 08855-1331, USA
 [phone]
 [phone] [FAX]


















 _N_o_v_e_m_b_e_r _1_9_9_1                                                    _S_H _X_X_X_X_X

 BEGIN_RATIONALE

 _E_d_i_t_o_r'_s _N_o_t_e_s

 This section will not appear in the  final  document.   It  is  used  for
 editorial comments concerning this draft.

 Comments in italics are not intended to form part  of  the  final  guide;
 they are editor's or coordinator comments for the benefit of reviewers.

 This draft uses small numbers in the right margin in lieu of change bars.  e
 ``E''  denotes changes from Draft 13 to Draft 14.  I have removed all old  e
 diff-marks from Drafts 3 through 13 to  facilitate  mock  ballot  review.  e
 Purely  editorial changes such as grammar, spelling, cross references, or  e
 removals of editorial notes are not diff-marked.   Unfortunately,  it  is  e
 not  possible  to  accurately  diff-mark the figures.  Note that an empty  e
 line with a diff mark denotes deleted text.  There are a large number  of  e
 these  in  Draft 14.  My convention is that I remove these empty lines in  e
 the next draft.                                                            e

 The references to standards and other  documents  are  still  awaiting  a  e
 reasonably  stable  draft for a massive global update.  I expect this may  e
 occur after the first round of official IEEE balloting.  The ISO and IEEE  e
 style  is  to  fully  identify  such  documents  in  either the Normative  e
 Reference clause or the Bibliography; each entry contains the full title,  e
 the  year  of  approval,  and  the current status (draft, CD, DIS, etc.).  e
 Elsewhere in the guide, a terse  reference  to  the  standard  number  is  e
 followed by the item number in the reference list, such as:                e

 POSIX.1 {2}                                                                e
 ISO/IEC 10646 {B33}                                                        e

 A few titles have been modified in Section 4 to adhere to the template     e
 for the services clauses.  These mostly affect the Standards,              e
 Specifications, and Gaps subclause and they are not diff-marked unless     e
 some significant text change accompanies them.                             e

 To make draft handling in the meetings easier, each significant clause is
 set up to print starting on a recto page.  This means that there is a
 larger number of blank pages than in previous drafts (assuming that the
 copy room handled the print master correctly).  Just doing our bit for
 deforestation ...

                                         Hal Jespersen





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.













 _E_d_i_t_o_r_i_a_l _C_o_n_t_a_c_t_s

 Please send comments regarding the content and approach of this document to:

         Fritz Schulz
         Open Software Foundation
         620 Herndon Parkway - Suite 200
         Herndon, VA  22070
         [phone]
         FAX: [phone]
         E-Mail: [e-mail]

 Please report typographical errors (and index suggestions) to:

         Hal Jespersen
         POSIX Software Group
         447 Lakeview Way
         Redwood City, CA 94062
         [phone]
         FAX: [phone]
         E-Mail: [e-mail]

 (Electronic mail is preferred.)




























              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.













 _O_n_l_i_n_e _A_c_c_e_s_s

 This draft is available in various electronic forms to assist the review
 process.  Our thanks to Andrew Hume of AT&T Bell Laboratories for
 providing online access facilities.  Note that this is a limited
 experiment in providing online access; future drafts may be provided in
 other forms, such as diskettes or a bulletin board arrangement, but the
 instructions shown here are the only methods currently available.  Please
 also observe the additional copyright restrictions that are described in
 the online files.

 Assuming you have access to the Internet, the scenario is approximately

       ftp research.att.com # research's IP address is 192.20.225.2
       <login as netlib; password is your email address>
       cd posix/p1003.0/d14
       get toc index
       binary
       get p11-20.Z

 The draft is available in several forms.  The table of contents can be
 found in toc, pages containing a particular section are stored under the
 section number, sets of pages are stored in files with names of the form
 p_n-_m, and the entire draft is stored in all.  By default, files are
 ASCII.  A .ps suffix indicates PostScript.  A .Z suffix indicates a
 compress'_e_d file.  The file index contains a general description of the
 files available.

 These files are also available via electronic mail by sending a message
 like

       echo send 3.4 4.6 6.2 from posix/p1003.0/d14 |                       e
               mail [e-mail]                                 e

 If you use email, you should _n_o_t ask for the compressed version.  For a
 more complete introduction to this form of _n_e_t_l_i_b, send the message

       send help













              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.













 _P_O_S_I_X._0 _C_h_a_n_g_e _H_i_s_t_o_r_y

 This section is provided to track major changes between drafts.  Since it
 was first added in Draft 10, earlier entries have been omitted.

    Draft 14       [November 1991] First mock ballot.                       e

                    - Software Development clause 4.11 moved to Annex E.    e

                    - _O_t_h_e_r _D_e_t_a_i_l_s _o_f _C_h_a_n_g_e_s _t_o _b_e _P_r_o_v_i_d_e_d               e

    Draft 13       [September 1991]

                    - _T_o _B_e _P_r_o_v_i_d_e_d

    Draft 12       [June 1991]

                    - Clause 4.9:  Separated OLTP model discussion into
                      two parts:  the part consistent with the POSIX OSE
                      Model; and the ``real world'' part dealing with
                      System Integration Interfaces.

                    - Section 6:  Further clarified ``base standard'' and
                      ``profile'' definitions.  Renamed profile ``types''.

                    - _A_d_d_i_t_i_o_n_a_l _T_o _B_e _P_r_o_v_i_d_e_d

    Draft 11       [March 1991]

                    - _T_o _B_e _P_r_o_v_i_d_e_d

                      _H_L_J:  _I _d_o_n'_t _d_o _t_h_i_s _a_u_t_o_m_a_t_i_c_a_l_l_y _b_e_c_a_u_s_e _I _d_o_n'_t
                      _k_n_o_w _w_h_a_t _i_s_s_u_e_s _y_o_u _c_o_n_s_i_d_e_r _i_m_p_o_r_t_a_n_t.  _T_h_i_s [_v_e_r_y
                      _b_r_i_e_f] _t_e_x_t _s_h_o_u_l_d _b_e _p_r_o_v_i_d_e_d _b_y _e_a_c_h _S_e_c_t_i_o_n
                      _L_e_a_d_e_r _a_l_o_n_g _w_i_t_h _t_h_e _r_e_g_u_l_a_r _s_u_b_m_i_s_s_i_o_n_s.  _I_t _i_s
                      _m_e_a_n_t _t_o _p_r_o_v_i_d_e _c_a_s_u_a_l _r_e_a_d_e_r_s _o_f _t_h_e _g_u_i_d_e (_s_u_c_h
                      _a_s _i_n _W_G_1_5, _w_h_e_r_e _t_h_e_y _d_o_n'_t _g_e_t _e_v_e_r_y _d_r_a_f_t) _w_i_t_h _a
                      _b_r_o_a_d _o_v_e_r_v_i_e_w _o_f _t_h_e _b_i_g _c_h_a_n_g_e_s.

    Draft 10       [December 1990]

                    - _T_o _B_e _P_r_o_v_i_d_e_d

 END_RATIONALE







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.














 IEEE Standards documents are developed within the Technical Committees of
 the IEEE Societies and the Standards Coordinating Committees of the IEEE
 Standards Board.  Members of the committees serve voluntarily and without
 compensation.  They are not necessarily members of the Institute.  The
 standards developed within IEEE represent a consensus of the broad
 expertise on the subject within the Institute as well as those activities
 outside of IEEE that have expressed an interest in participating in the
 development of the standard.

 Use of an IEEE Standard is wholly voluntary.  The existence of an IEEE
 Standard does not imply that there are no other ways to produce, test,
 measure, purchase, market, or provide other goods and services related to
 the scope of the IEEE Standard.  Furthermore, the viewpoint expressed at
 the time a standard is approved and issued is subject to change brought
 about through developments in the state of the art and comments received
 from users of the standard.  Every IEEE Standard is subjected to review
 at least every five years for revision or reaffirmation.  When a document
 is more than five years old and has not been reaffirmed, it is reasonable
 to conclude that its contents, although still of some value, do not
 wholly reflect the present state of the art.  Users are cautioned to
 check to determine that they have the latest edition of any IEEE
 Standard.

 Comments for revision of IEEE Standards are welcome from any interested
 party, regardless of membership affiliation with IEEE.  Suggestions for
 changes in documents should be in the form of a proposed change of text,
 together with appropriate supporting comments.

 Interpretations:  Occasionally questions may arise regarding the meaning
 of portions of standards as they relate to specific applications.  When
 the need for interpretations is brought to the attention of the IEEE, the
 Institute will initiate action to prepare appropriate responses.  Since
 IEEE Standards represent a consensus of all concerned interests, it is
 important to ensure that any interpretation has also received the
 concurrence of a balance of interests.  For this reason, the IEEE and the
 members of its technical committees are not able to provide an instant
 response to interpretation requests except in those cases where the
 matter has previously received formal consideration.

 Comments on standards and requests for interpretations should be
 addressed to:

       Secretary, IEEE Standards Board
       445 Hoes Lane
       P.O. Box 1331
       Piscataway, NJ 08855-1331




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.













        ___________________________________________________________
       | IEEE Standards documents are adopted by the Institute of |
       | Electrical and Electronics Engineers without regard to   |
       | whether their adoption may involve patents on articles,  |
       | materials, or processes.  Such adoption does not assume  |
       | any liability to any patent owner, nor does it assume any|
       | obligation whatever to parties adopting the standards    |
       | documents.                                               |
       |___________________________________________________________|










































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.















                                 Contents


                                                                      PAGE
 Introduction.......................................................     v
    Purpose.........................................................     v
    The POSIX Open System Environment Reference Model...............    vi
    Goals...........................................................   vii
    Benefits........................................................  viii
    Related Standards Activities....................................     x

 Section 1: General.................................................     1
    1.1   Scope.....................................................     1
    1.2   Normative References......................................     2
    1.3   Conformance...............................................     3
    1.4   Test Methods..............................................     3

 Section 2: Terminology and General Requirements....................     5
    2.1   Conventions...............................................     5
    2.2   Definitions...............................................     5
          2.2.1  Terminology........................................     5
          2.2.2  General Terms......................................     7
          2.2.3  Abbreviations......................................    13

 Section 3: POSIX Open System Environment...........................    15
    3.1   POSIX Open System Environment - General Requirements......    16
    3.2   POSIX Open System Environment Reference Model.............    19
    3.3   POSIX Open System Environment Services....................    28
    3.4   POSIX Open System Environment Standards...................    29
    3.5   POSIX Open System Environment Profiles....................    32
    3.6   Application Platform Implementation Considerations........    33

 Section 4: POSIX Open System Environment Services..................    39
    4.1   Language Services.........................................    43
    4.2   System Services...........................................    53
    4.3   Network Services..........................................    73
    4.4   Database Services.........................................    99
    4.5   Data Interchange Services.................................   111
    4.6   Transaction Processing Services...........................   119
    4.7   Graphical Window System Services..........................   131
    4.8   Graphics Services.........................................   149
    4.9   Character-Based User Interface Services...................   171
    4.10  User Command Interface Services...........................   177

 Section 5: POSIX OSE Cross-Category Services.......................   187
    5.1   Internationalization......................................   189
    5.2   System Security Services..................................   209


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 ii








                                                                      PAGE
    5.3   Information System Management.............................   215

 Section 6: Profiles................................................   227
    6.1   Scope.....................................................   227
    6.2   Profile Concepts..........................................   228
    6.3   Guidance to Profile Writers...............................   230

 Section 7: POSIX SP Profiling Efforts..............................   237
    7.1   Introduction..............................................   237
    7.2   General Purpose POSIX SPs.................................   237

 Annex A (informative) Considerations for Developers of POSIX SPs...   249
    A.1   Introduction..............................................   249
    A.2   Scope.....................................................   249
    A.3   The Role of POSIX SPs.....................................   250
    A.4   Special Rules for POSIX SPs...............................   251
    A.5   Other Issues..............................................   253
    A.6   Conformance to a POSIX SP.................................   255
    A.7   Structure of Documentation for POSIX SPs..................   255
    A.8   Rules for Drafting and Presentation of POSIX SPs..........   257

 Annex B (informative) Bibliography.................................   262

 Annex C (informative) Standards Infrastructure Description.........   265
    C.1   Introduction..............................................   265
    C.2   The Formal Standards Groups...............................   267
    C.3   Related Organizations.....................................   281

 Annex D (informative) Electronic-Mail..............................   295

 Annex E (informative) Additional Material..........................   297
    E.1   Software Development Environments.........................   297

 Alphabetic Topical Index...........................................   307


 FIGURES

 Figure 3-1  -  POSIX OSE Reference Model............................   20
 Figure 3-2  -  POSIX OSE Reference Model - Entities.................   22
 Figure 3-3  -  POSIX OSE Reference Model - Interfaces...............   24
 Figure 3-4  -  POSIX OSE Reference Model - Distributed Systems......   28
 Figure 3-5  -  Distributed System Environment Model.................   29
 Figure 3-6  -  Service Components and Interfaces....................   33
 Figure 3-7  -  Application Platform Implementation - Subdivision....   35
 Figure 3-8  -  Application Platform Decomposition II - Layering.....   36
 Figure 3-9  -  Application Platform Decomposition III -
    Redirection......................................................   36


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




                                                                       iii









 Figure 4-1  -  Language Service Reference Model.....................   44
 Figure 4-2  -  System Services Reference Model......................   54
 Figure 4-3  -  POSIX Networking Reference Model.....................   74
 Figure 4-4  -  OSI Reference Model..................................   77
 Figure 4-5  -  Relationship of OSI and POSIX OSE Network Reference
    Models...........................................................   79
 Figure 4-6  -  Multiple POSIX OSE APIs to Different OSI Layers......   80
 Figure 4-7  -  POSIX Network Services Model.........................   81
 Figure 4-8  -  Directory Services Architecture......................   83
 Figure 4-9  -  OSI Network Services Standards.......................   94
 Figure 4-10  -  The Traditional Database Model......................  100
 Figure 4-11  -  POSIX Database Reference Model......................  101
 Figure 4-12  -  Data Interchange Reference Model....................  112
 Figure 4-13  -  The Conventional Transaction Processing Model.......  121
 Figure 4-14  -  POSIX OSE Transaction Processing Reference Model....  123
 Figure 4-15  -  Windowing Reference Model...........................  133
 Figure 4-16  -  Computer Graphics Reference Model Level Structure...  153
 Figure 4-17  -  POSIX OSE Graphics Service Reference Model..........  154
 Figure 4-18  -  POSIX OSE Graphics Service Reference Model
    Standards........................................................  160
 Figure 4-19  -  Character-based Terminal Reference Model............  172
 Figure 4-20  -  POSIX OSE Reference Model for Command Interfaces....  178
 Figure A-1  -  Universe of Profiles and Standards...................  250
 Figure C-1  -  Selected Major Standards and Standards-Influencing
    Bodies...........................................................  267
 Figure C-2  -  IEEE Standards Diagram...............................  277
 Figure E-1  -  Software Development Model...........................  299
 Figure E-2  -  Software Development Reference Model.................  300


 TABLES

 Table 4-1  -  Language Standards....................................   49
 Table 4-2  -  System Services Standards.............................   65
 Table 4-3  -  Functionality of POSIX.1 Standard.....................   67
 Table 4-4  -  Networking Standards..................................   92
 Table 4-5  -  Database Standards....................................  107
 Table 4-6  -  Data Interchange Standards............................  115
 Table 4-7  -  Transaction Processing Standards......................  128
 Table 4-8  -  Transaction Processing Standards Language Bindings....  128
 Table 4-9  -  Windowing Standards...................................  145
 Table 4-10  -  Graphics Standards...................................  161
 Table 4-11  -  Graphics Standards Language Bindings.................  162
 Table 4-12  -  Shell and Utilities Standards........................  183
 Table 5-1  -  Internationalization Standards........................  201
 Table 5-2  -  Security Standards....................................  213
 Table 7-1  -  POSIX SPs In Progress.................................  238
 Table E-1  -  Software Development Standards........................  302


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 iv











                               Introduction



 (This Introduction is not a normative part of P1003.0 Guide to the POSIX
 Open Systems Environment, but is included for information only.)


 Purpose

 There are many standards efforts going on throughout the world today.
 Standards are being developed in many areas of computing technology such
 as:

     - Electrical Connectors

     - Disk Interfaces

     - Network Interfaces

     - Application Program Interfaces

 Each standards effort typically addresses a very small portion of the
 overall needs of an information processing system.

 This guide brings together many different standards sufficient to address  e
 the scope of an entire information processing system.  This combination
 of standards and specifications that are sufficient to address all of the
 user requirements of an information processing system is called an Open
 System Environment.  This guide is not a base standard itself; it merely   e
 identifies standards that can be used when constructing a complete         e
 information processing system.  Although this guide is a product of the    e
 IEEE POSIX standardization effort, its scope is much broader than the      e
 IEEE POSIX standardization efforts.  IEEE POSIX is currently developing    e
 base standards and standardized profiles focused primarily on application  e
 programming interfaces.  At the end of the Introduction is a cross         e
 reference of the POSIX standardization efforts and where they fit in the   e
 POSIX Open System Environment.                                             e

 User requirements and standards to meet those requirements are
 continuously expanding.  As such, this guide will need regular revision
 to incorporate new user requirements and the new standards that evolve to
 meet those user requirements.

 It may never be necessary to implement an information processing system
 that provides every standard in the POSIX Open System Environment.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Purpose                                                                 v








 Typically, a subset of the POSIX Open System Environment is sufficient to  e
 satisfy the particular user requirements in each situation.

 This process of selecting standards for a particular application is
 called profiling.  Recommendations for the production of different types
 of profiles are included in the guide.

 This guide is intended to be used by anyone interested in using standards  e
 in an information processing system, including:  consumers, systems
 integrators, application developers, systems providers, and procurement
 agencies.

 Taken as a whole, the guide maps existing and emerging standards onto the
 general requirements of a complete information processing system.  In
 addition to listing and categorizing existing standards efforts, the
 guide identifies important requirements that standards efforts have not
 yet addressed.

 The POSIX Open System Environment Reference Model

 To describe the POSIX Open System Environment, the guide develops a
 reference model used to classify information processing standards.  The
 reference model divides standards into two general categories:             e

    Application Program Interface Standards

          These standards affect how application software interacts with
          the computer system.  These standards affect application
          portability.

    Platform External Interface Standards

          These standards affect how an information processing system
          interacts with its external environment.  These standards affect
          system interoperability, user interface look and feel, and data
          portability.

 These standards are very important because they allow a user to
 independently procure portions of their information processing systems
 from multiple vendors according to each user's needs.

 In addition to these two interfaces identified in the model, there are     e
 other important interface between different computer system components:    e
 System Internal Interfaces.  These interfaces have no direct impact on     e
 the external interface of a system or the application program interface    e
 to the system.  System Internal Interfaces are beyond the direct scope of  e
 this guide because they do not directly impact application portability or  e
 system interoperability.                                                   e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 vi                                                           Introduction








 The services provided by the application platform are classified into      e
 four major categories:                                                     e

     - System services                                                      e

     - Communications services                                              e

     - Information services                                                 e

     - Human-computer interaction services                                  e

 Within these categories, services component areas are identified.          e

 Using the reference model, a general set of requirements for each
 component area is developed.  For each of the requirements existing or
 emerging standards are identified that address the requirement.  If a
 requirement is not completely met by an existing or emerging standard,
 this gap in the standards is noted.

 Goals

 There are three goals of the POSIX OSE:  portability, interoperability,
 and user portability.  (While these terms are formally defined later in
 this guide and within various referenced standards, the following
 descriptions provide an overview of their meaning.)

    Portability

          Source Code Portability is accomplished through the use of the    e
          respective system/application interface standards and their
          extensions, thus allowing a user's application to operate on a
          wide range of systems.  It is important to note that the
          aforementioned phrase ``wide range of systems'' connotes diverse
          hardware as well as software platforms.

                                                                            e

    Interoperability

          Interoperability is characterized by the cooperative operation
          of applications resident on dissimilar computer systems.  This
          cooperative operation is illustrated by data and functionality
          exchange.

    User Portability

          A consistent user interface allows users to move from system to   e
          system and between different applications on the same system
          with a minimum of retraining.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Goals                                                                 vii








 Benefits

 The benefits derived in the use of the POSIX Open System Environment are
 real and quantifiable.

    Simplified Vendor Mixing System Integration

          As the standards for system integration and system
          interoperability are produced and implemented, the users will
          have the choice of mixing software and equipment from multiple
          vendors.  This will allow users to tailor their information
          processing system to their particular needs by selecting their
          hardware based on the application needs rather than its ability
          to interoperate with their existing equipment.

    Efficient Development and Implementation

          Normally, systems users and providers have development and
          implementation activities that utilize personnel possessing
          skills in a specific computer environment.  As a result of this
          specialization, a change in the target computer environment for
          a developer requires significant retraining expense.  As
          standards for application portability, system interoperability,
          and system integration are developed, computer personnel will
          begin to develop skills in working with these standards.  When
          these standards are widely used there will be large pool of
          personnel who are familiar with working with the standards.

          This will allow a company to hire personnel with existing skills
          that can be put to use in their operation.  In addition, within
          a company, resources can be redeployed between development
          efforts with a minimum of retraining.

          As the basic interfaces are developed and well defined, higher
          level standardized interfaces can be developed that add value to
          the basic interfaces.  Using the higher level interfaces may
          speed development efforts.

    Efficient Porting of Applications

          The difficulty of moving an application from one
          hardware/software environment to another is widely known.  The
          porting of an application that uses standards-based interfaces
          to another system that provides the same standards-based
          interfaces is considerably simpler than ports involving
          completely different systems.  The amount of system tailoring
          (i.e., changes to either the operating or application system
          required to make them work well together) is greatly reduced.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 viii                                                         Introduction








          It is important to note that while standards-based systems        e
          enable applications to be ported between different systems, the   e
          standards do not guarantee that an application will be portable.  e
          Applications still must be properly engineered to ensure          e
          application portability.                                          e

    Broadened Basis for Computer System Procurement Decisions

          Computer users can now select and match hardware and software
          components from potentially different suppliers to fulfill an
          application requirement.  This in turn allows decisions
          regarding computer systems procurements to be based less upon
          constraints imposed by incumbent vendors' products.  The basis
          for competition will refocus on such factors as price, quality,
          value-added features, performance, and support.  The stimulation
          of competition will benefit providers and users.

                                                                            e

































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Benefits                                                               ix








 Related Standards Activities

 The Standards Subcommittee of the IEEE Technical Committee on Operating
 Systems and Application Environments has authorized other standards
 activities that are related to the content of this guide.

 The following table summarizes the current POSIX standardization           e
 efforts1) and how they fit into this guide:                                e

      Project                 Standard/Profile                Clause        e
      ________   __________________________________________   ______        e
      P1003.1    System Interfaces                             4.2          e
      P1003.2    Shell and Utilities                           4.9          e
      P1003.3    Test Methods                                               e
      P1003.4    Realtime                                      4.2          e
      P1003.5    Ada Bindings                                  4.2          e
      P1003.6    Security                                      5.2          e
      P1003.7    System Administration                         5.3          e
      P1003.8    Transparent File Access                       4.3          e
      P1003.9    Fortran Bindings                              4.2          e
      P1003.10   Supercomputing Profile                        7.2          e
      P1003.11   Transaction Processing Profile                7.2          e
      P1003.12   Protocol-Independent Network Specification    4.3          e
      P1003.13   Realtime Profile                              7.2          e
      P1003.14   Multiprocessing Profile                       7.2          e
      P1003.15   Batch System                                  4.9          e
      P1003.16   C-Language Bindings                           4.2          e
      P1003.17   Directory/Name Services                       4.3          e
      P1003.18   POSIX Platform Profile                        7.2          e
      P1201.1    Human-Computer Interfaces                     4.6          e
      P1201.2    User Interface Drivability                    4.6          e
      P1224      X.400 API                                     4.3          e
      P1237      RPC                                           4.3          e
      P1238.0    FTAM API                                      4.3          e
      P1238.1    OSI Networking API                            4.3          e

 Most of these efforts are in the areas of API standards and standardized   e
 profiles.                                                                  e



 __________
  1) A _S_t_a_n_d_a_r_d_s _S_t_a_t_u_s _R_e_p_o_r_t that lists all current IEEE Computer
     Society standards projects is available from the IEEE Computer
     Society, 1730 Massachusetts Avenue NW, Washington, DC 20036-1903;
     Telephone: [phone]; FAX: [phone].  Working drafts of
     POSIX standards under development are also available from this
     office.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 x                                                            Introduction








 Extensions are approved as ``amendments'' or ``revisions'' to this
 document, following the IEEE and ISO/IEC Procedures.

 Approved amendments are published separately until the full document is
 reprinted and such amendments are incorporated in their proper positions.

 If you have interest in participating in the TCOS working groups
 addressing these issues, please send your name, address, and phone number
 to the Secretary, IEEE Standards Board, Institute of Electrical and
 Electronics Engineers, Inc., P.O. Box 1331, 445 Hoes Lane, Piscataway, NJ
 08855-1331, and ask to have this forwarded to the chairperson of the
 appropriate TCOS working group.  If you have interest in participating in
 this work at the international level, contact your ISO/IEC national body.

 P1003.0 was prepared by the 1003.0 working group, sponsored by the
 Technical Committee on Operating Systems and Application Environments of
 the IEEE Computer Society.  At the time this standard was approved, the
 membership of the 1003.0 working group was as follows:

                 Technical Committee on Operating Systems
                    and Application Environments (TCOS)

                       Chair:   Jehan-Franc,ois Pa^ris

                        TCOS Standards Subcommittee

                       Chair:         Jim Isaak
                       Vice Chairs:   Ralph Barker
                                      Robert Bismuth
                                      Hal Jespersen
                                      Lorraine Kevra
                                      Pete Meier
                       Treasurer:     Quin Hahn
                       Secretary:     Shane McCarron

                      1003.0 Working Group Officials

       Chair:              Allen Hankinson
       Vice Chair:         Kevin Lewis
       Document Editor:    Hal Jespersen (sponsored by Mike Lambert)
       Technical Editor:   Fritz Schulz
       Secretary:          Charles Severance

                               Working Group

 <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d>     <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d>     <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d>





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




                                                                        xi








 The following persons were members of the 1003.0 Balloting Group that
 approved the standard for submission to the IEEE Standards Board:

            <_N_a_m_e>   <_I_n_s_t_i_t_u_t_i_o_n> _I_n_s_t_i_t_u_t_i_o_n_a_l _R_e_p_r_e_s_e_n_t_a_t_i_v_e

 <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d>     <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d>     <_N_a_m_e _t_o _b_e _p_r_o_v_i_d_e_d>

 When the IEEE Standards Board approved this standard on <_d_a_t_e _t_o _b_e
 _p_r_o_v_i_d_e_d>, it had the following membership:







                                   (to be pasted in by IEEE)


































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 xii                                                          Introduction






                                                               P1003.0/D14












 Guide to the POSIX Open Systems Environment








                            Section 1: General



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _K_e_v_i_n _L_e_w_i_s



 1.1  Scope

 This guide identifies parameters for an open system environment using the
 POSIX operating system/application interface as the platform.  These
 parameters are determined in three basic ways:

     (1)  By specifying building blocks identified as components

          Currently these components are:  system services, networking,
          human/computer interaction (HCI), graphics, system security and
          privacy, database, data interchange, and language requirements.
          This guide identifies the standards required within each
          component to achieve the goals of a POSIX open system.

     (2)  By identifying intra- and intercomponent issues

          These issues involve the relationships that should exist between
          and among the different components.  It is in the attempt to lay
          out and address these relationships that the concept of profiles
          (see 2.2.2 and Section 6) arises.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 1.1 Scope                                                               1






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     (3)  By identifying voids

          A void is determined by the absence, or lack of maturity, of
          formal standards development efforts.  Voids may exist within
          available standards or may be an entire component.  This guide
          provides assistance to those users who have already constructed,
          or plan to construct, profiles and to those users who currently
          use, or plan to use, profiles.  The profile concept allows users
          to identify those standards that address their specific needs.
          The profile also serves to identify the need for future
          standards development in a specific area.  This guide explains
          the manner in which these standards relate to each other.



 1.2  Normative References

 _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s:  _T_h_i_s _c_l_a_u_s_e _i_s _n_o_t _c_o_m_p_l_e_t_e.  _A _l_i_s_t _o_f _r_e_f_e_r_e_n_c_e_d     _e
 _s_t_a_n_d_a_r_d_s _a_n_d _o_t_h_e_r _p_u_b_l_i_c_a_t_i_o_n_s _n_e_e_d_s _t_o _b_e _p_r_o_v_i_d_e_d, _c_o_n_t_r_a_s_t_e_d _a_g_a_i_n_s_t  _e
 _t_h_e _l_i_s_t _o_f _i_n_t_e_r_e_s_t_i_n_g _b_a_c_k_g_r_o_u_n_d _d_o_c_u_m_e_n_t_s _t_h_a_t _s_h_o_u_l_d _g_o _i_n_t_o _t_h_e       _e
 _b_i_b_l_i_o_g_r_a_p_h_y, _i_n_c_l_u_d_e_d _a_s _A_n_n_e_x _B.  _I_t _c_u_r_r_e_n_t_l_y _c_o_n_s_i_s_t_s _o_n_l_y _o_f _s_a_m_p_l_e   _e
 _e_n_t_r_i_e_s.  _I_t _w_i_l_l _b_e _r_e_p_l_a_c_e_d _i_n _a _l_a_t_e_r _d_r_a_f_t.                            _e

 The following standards contain provisions which, through references in
 this text, constitute provisions of this guide.  At the time of
 publication, the editions indicated were valid.  All standards are
 subject to revision, and parties to agreements based on this part of this
 International Standard are encouraged to investigate the possibility of
 applying the most recent editions of the standards listed below.  Members
 of IEC and ISO maintain registers of currently valid International
 Standards.

 {1}   ISO 8859-1: 1987, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g--_8-_b_i_t _s_i_n_g_l_e-_b_y_t_e _c_o_d_e_d
       _g_r_a_p_h_i_c _c_h_a_r_a_c_t_e_r _s_e_t_s--_P_a_r_t _1: _L_a_t_i_n _a_l_p_h_a_b_e_t _N_o. _1.1)

 {2}   ISO/IEC 9945-1: 1990, _I_n_f_o_r_m_a_t_i_o_n _t_e_c_h_n_o_l_o_g_y--_P_o_r_t_a_b_l_e _o_p_e_r_a_t_i_n_g
       _s_y_s_t_e_m _i_n_t_e_r_f_a_c_e (_P_O_S_I_X)--_P_a_r_t _1:  _S_y_s_t_e_m _a_p_p_l_i_c_a_t_i_o_n _p_r_o_g_r_a_m_m_i_n_g
       _i_n_t_e_r_f_a_c_e (_A_P_I) [_C _L_a_n_g_u_a_g_e]







 __________
  1) ISO documents can be obtained from the ISO office, 1, rue de Varembe',
     Case Postale 56, CH-1211, Gene`ve 20, Switzerland/Suisse.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 2                                                               1 General






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 1.3  Conformance

 Not applicable.



 1.4  Test Methods                                                          e

 Not applicable.                                                            e










































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 1.4 Test Methods                                                        3








































































                                                               P1003.0/D14








              Section 2: Terminology and General Requirements



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _J_o_h_n _W_i_l_l_i_a_m_s



 2.1  Conventions

 This guide uses the following typographic conventions:

     - The _i_t_a_l_i_c font is used for cross references to defined terms
       within 1.3, 2.2.1, and 2.2.2.

 In some cases tabular information is presented ``inline''; in others it
 is presented in a separately labeled Table.  This arrangement was
 employed purely for ease of typesetting and there is no normative
 difference between these two cases.

 The typographic conventions listed above are for ease of reading only.
 Editorial inconsistencies in the use of typography are unintentional and
 have no normative meaning in this guide.

 NOTEs provided as parts of labeled Tables and Figures are integral parts
 of this guide (normative).  Footnotes and NOTEs within the body of the
 text are for information only (nonnormative).



 2.2  Definitions


 2.2.1  Terminology

 For the purposes of this guide, the following definitions apply:

 2.2.1.1  implementation defined:  An indication that the implementation
 shall define and document the requirements for correct program constructs
 and correct data of a value or behavior.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 2.2 Definitions                                                         5






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 2.2.1.2  informative:  Providing or disclosing information; instructive.

 Used in standards to indicate a portion of the text that poses no
 requirements; the opposite of _n_o_r_m_a_t_i_v_e.

 2.2.1.3  may:  An indication of an optional feature.

 With respect to implementations, the word _m_a_y is to be interpreted as an
 optional feature that is not required in this guide, but can be provided.

 2.2.1.4  normative:  Of, pertaining to, or prescribing a norm or
 standard.

 Used in standards to indicate a portion of the text that poses
 requirements.

 2.2.1.5  should:  With respect to implementations, an indication of an
 implementation recommendation, but not a requirement.

 2.2.1.6  POSIX:  The term ``POSIX'' has been evolving recently into a
 generally positive term with, unfortunately, a number of different
 meanings.  This subclause attempts to define the word and some related
 terms.  The intent is to insure that the term POSIX is used in a useful
 and predictable manner in this document.

 As background, note that POSIX is sometimes used to denote the formal
 standard IEEE Std 1003.1-1990, sometimes to denote that standard plus
 related standards and drafts emerging from IEEE P1003.x working groups,
 and sometimes to denote the groups themselves.  In all those cases, it
 should be noted, POSIX is used as a noun.

 This document will use the term ``POSIX'' only as an adjective, and will
 use it only in well defined ways.  This subclause serves as a preview of
 the usages in this book of POSIX terms.  (These terms are defined,
 formally, or informally in subsequent clauses, and you will be referred
 to those clauses as appropriate.)

 The original POSIX standard will be referred to by its name, ISO 9945,
 and not by the term POSIX.

 The IEEE groups developing standards related to ISO 9945 are called, in
 this document, _P_O_S_I_X _w_o_r_k_i_n_g _g_r_o_u_p_s.  Examples are the IEEE working
 groups P1003.2, P1003.3, etc.  The groups' names will be abbreviated
 POSIX.2, POSIX.3, etc.

 The standards emerging out of the POSIX working groups will be referred
 to by their formal names (e.g., IEEE P1003.2 Draft 9) and are called
 either _P_O_S_I_X _B_a_s_e _S_t_a_n_d_a_r_d_s or _P_O_S_I_X _S_t_a_n_d_a_r_d_i_z_e_d _P_r_o_f_i_l_e_s (POSIX SPs).



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 6                                  2 Terminology and General Requirements






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 2.2.2  General Terms

 For the purposes of this guide, the following definitions apply:

 2.2.2.1  application:  The use of capabilities (services/facilities)
 provided by an information system specific to the satisfaction of a set
 of user requirements.
 NOTE:  These capabilities include hardware, software, and data.

 2.2.2.2  application platform:  A set of resources that support the
 services on which an application or application software will run.

 The application platform provides services at its interfaces that, as
 much as possible, make the specific characteristics of the platform
 transparent to the application.

 2.2.2.3  application program interface (API):  The interface between the
 applications software and the applications platform, across which all
 services are provided.

 The application program interface is primarily in support of application
 portability, but system and application interoperability are also
 supported via the communications API.

 2.2.2.4  application software:  Software that is specific to an
 application and is composed of programs, data, and documentation.

 2.2.2.5  Application Environment Profile (AEP):  A profile, specifying a   e
 complete and coherent subset of the OSE, in which the standards, options,  e
 and parameters chosen are necessary to support a class of applications.

                                                                            e

 2.2.2.6  base standard:  A standard or specification that is recognized
 as appropriate for normative reference in a profile by the body adopting
 that profile.

 2.2.2.7  Communications Interface:  The boundary between application
 software and the external environment, such as other application
 software, external data transport facilities, and devices.

 The services provided are those whose protocol state, syntax, and format
 all must be standardized for interoperability.

                                                                            e

 2.2.2.8  External Environment Interface (EEI):  The interface between the
 application platform and the external environment across which
 information is exchanged.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 2.2 Definitions                                                         7






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 The External Environment Interface is defined primarily in support of
 system and application interoperability.

 The primary services present at the External Environment Interface
 comprise:

     - Human/Computer Interaction Services

     - Information Services

     - Communications Services

 2.2.2.9  external environment:  A set of external entities to the
 application platform in which information is exchanged.

 These devices include displays, disk drives, sensors, and effectors
 directly accessible within the system.

 2.2.2.10  hardware:  Physical equipment used in data processing as
 opposed to programs, procedures, rules, and associated documentation.

 2.2.2.11  Human/Computer Interface:  The boundary across which physical
 interaction between a human being and the application platform takes
 place.

 2.2.2.12  Information Interchange Interface:  The boundary across which
 external, persistent storage service is provided.

 Only the format is required to be specified for data portability and
 interoperability.

 2.2.2.13  interface:  The shared boundary between two functional units,
 defined by functional characteristics and other characteristics, as
 appropriate.

 2.2.2.14  internationalization:  The process of designing and developing
 a product with a set of features, functions, and options intended to
 facilitate the adaptation of the product to satisfy a variety of cultural
 environments.

 2.2.2.15  interoperability:  The ability of two or more systems to
 exchange information and to mutually use the information that has been
 exchanged.

 2.2.2.16  language-binding API:  The interface between applications and
 application platforms based on language-independent binding APIs and
 consistent with the paradigms used for a specific programming language.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 8                                  2 Terminology and General Requirements






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 2.2.2.17  language-independent service specification:  A specification
 that facilitates the management and development of consistent language-
 binding standards.

 2.2.2.18  locale:  A description of a cultural environment.

 2.2.2.19  localization:  The process of utilizing the
 internationalization features to create a version of the product for a
 specific culture.

 2.2.2.20  local adaptation:  The process of modifying a product that has
 hard-coded biases of one culture to the hard-coded biases of another
 culture.

 2.2.2.21  open specifications:  Public specifications that are maintained
 by an open, public consensus process to accommodate new technologies over
 time and that are consistent with international standards.

 2.2.2.22  Open System Application Program Interface:  A combination of
 standards-based interfaces specifying a complete interface between an
 application program and the underlying application platform.

 This is divided into the following parts:

     - Human/Computer Interaction Services API

     - Information Services API

     - Communications Services API

     - System Services API

 2.2.2.23  open system:  A system that implements sufficient open
 specifications for interfaces, services, and supporting formats to enable
 properly engineered applications software:

     - to be ported with minimal changes across a wide range of systems

     - to interoperate with other applications on local and remote systems

     - to interact with users in a style that facilitates user
       portability.

 2.2.2.24  Open System Environment (OSE):  The comprehensive set of
 interfaces, services, and supporting formats, plus user aspects for
 interoperability or for portability of applications, data, or people, as
 specified by information technology standards and profiles.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 2.2 Definitions                                                         9






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 2.2.2.25  performance:  A measure of a computer system or subsystem to
 perform its functions; for example, response time, throughput, number of
 transactions per second.

 2.2.2.26  performance evaluation:  The technical assessment of a system
 or system component to determine how effectively operating objectives
 have been achieved.

 2.2.2.27  performance requirement:  A requirement that specifies a
 performance characteristic that a system or system component must
 possess; for example, speed, accuracy, frequency.

 2.2.2.28  portability:  The ease with which software can be transferred
 from one information system to another.

 2.2.2.29  POSIX Open System Environment (POSIX OSE):  The Open System
 Environment in which the standards included are International, Regional,
 and National Information Technology Standards and profiles that are in
 accord with ISO/IEC 9945 (POSIX).

 This guide represents the POSIX OSE as it existed when the guide was
 approved.

 2.2.2.30  POSIX OSE Cross-Category Services:  A set of tools and/or
 features that has a direct effect on the operation of one or more
 component of the POSIX Open System Environment, but is not in and of
 itself a stand-alone component.

 2.2.2.31  POSIX Standardized Profile (POSIX SP):  A Standardized Profile
 that specifies the application of certain POSIX base standards in support
 of a class of applications and does not require any departure from the
 structure defined by the POSIX.0 Reference Model for POSIX systems.
 NOTE:  Which POSIX base standards form the basis of the POSIX SPs is
 still open.  Annex A discusses some of the issues involved.

 2.2.2.32  process:  An address space and single thread of control that
 executes within that address space, and its required system resources.

 A process is created by another process issuing the _f_o_r_k() function.  The
 process that issues _f_o_r_k() is known as the parent process, and the new
 process created by the _f_o_r_k() as the child process.

 2.2.2.33  profile:  A set of one or more base standards, and, where
 applicable, the identification of chosen classes, subsets, options, and
 parameters of those base standards, necessary for accomplishing a
 particular function.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 10                                 2 Terminology and General Requirements






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 2.2.2.34  programming language API:  The interface between applications
 and application platforms traditionally associated with programming
 language specifications, such as program control, math functions, string
 manipulation, etc.

 2.2.2.35  protocol (OSI):  A set of semantic and syntactic rules that
 determine the behavior of [OSI-] entities in the same layer in performing
 communication functions.

 2.2.2.36  redirection:  A system profile construction method of starting
 at a base platform and adding new services by allowing a service
 component to ask the base platform to redirect all requests for that type
 of service to the service component.

 2.2.2.37  public specifications:  Specifications that are available,       e
 without restriction, to anyone for implementation and distribution (i.e.,  e
 sale) of that implementation.                                              e

 2.2.2.38  reference model:  A simplified description or representation of
 something.

 2.2.2.39  scaleability:  The ease with which software can be transferred
 from one graduated series of application platforms to another.

                                                                            e

 2.2.2.40  security:  The protection of computer hardware and software
 from accidental or malicious access, use, modification, destruction, or
 disclosure.

 Tools for the maintenance of security are focused on availability,
 confidentiality, and integrity.

 2.2.2.41  service delivery latency:  The interval between (a) context
 switch from an application context to the operating system context, and
 (b) satisfaction of the service request.

 2.2.2.42  service request latency:  The interval between (a) context
 switch from an application context to the operating system context, and
 (b) the reverse context switch from the operating system context to the
 application context for a given service request.

 2.2.2.43  software:  The programs, procedures, rules, and any associated
 documentation pertaining to the operation of a data processing system.

 2.2.2.44  specification:  A document that prescribes, in a complete,
 precise, verifiable manner, the requirements, design, behavior, or
 characteristics of a system or system component.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 2.2 Definitions                                                        11






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 2.2.2.45  standardized profile:  A balloted, formal, harmonized document
 that specifies a profile.

 2.2.2.46  standards:  Documents, established by consensus and approved by
 a recognized body, that provide, for common and repeated use, rules,
 guidelines, or characteristics for activities or their results, aimed at
 the achievement of the optimum degree of order in a given context.

                                                                            e

 2.2.2.47  System Internal Interface (SII):  The interface between
 application platform service components within that platform; it may be
 standardized or nonstandard.

 2.2.2.48  system services:  Firmware and software that provide an
 aggregation of network element functions into a higher level function;
 provide an interface to the data contained in the system.

 2.2.2.49  System Services API:  An interface providing access to services
 associated with the application's internal resources.

 The System Services API has two parts:  Language Specifications and
 Processing Services API.

 2.2.2.50  system software:  Application-independent software that
 supports the running of application software.

 2.2.2.51  transaction:  A unit of work consisting of an arbitrary number
 of individual operations all of which will complete successfully (or be
 of no effect) on the intended resources.

 A transaction has well defined boundaries.  A transaction starts with a
 request from the application program and either completes successfully
 (commits) or has no effect (abort).  Both the commit and abort signify a
 transaction completion.

 2.2.2.52  transaction application program:  A program written to meet the
 requirements of a chosen Transaction Processing (TP) application.

 Such programs allow a sequence of operations that involve resources such
 as terminals and databases.  The transaction AP specifies transaction
 boundaries.  The transaction AP as defined here is a logical entity and
 may involve an arbitrary number of processes.

 2.2.2.53  validation:  The process of evaluating a ported application,
 software, or system to ensure compliance with requirements.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 12                                 2 Terminology and General Requirements






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 2.2.3  Abbreviations

 For the purposes of this guide, the following abbreviations apply:

 2.2.3.1  API:  Application Program Interface

 2.2.3.2  EEI:  External Environment Interface

 2.2.3.3  POSIX.0:  This guide.

 2.2.3.4  POSIX._nnnn:  An IEEE POSIX working group, where the number _n
 represents the decimal notation in the IEEE P1003 series.  Alternatively,
 when apparent from context, the latest standard issued, or under
 development, by that working group.

 2.2.3.5  SII:  System Internal Interface.



































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 2.2 Definitions                                                        13








































































                                                               P1003.0/D14








                 Section 3: POSIX Open System Environment



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _F_r_i_t_z _S_c_h_u_l_z

 The POSIX Open System Environment (OSE) is a collection of concepts that
 provide a context for user requirements and standards specification.  It
 provides a minimum, standard set of conceptual information system
 building blocks with associated interfaces and functionality.  The POSIX
 OSE consists of a reference model, service definitions, standards, and
 profiles.

 These OSE concepts are also intended to be conventional within computer
 science.  The intention is not to break new ground, but to establish a
 minimum and unambiguous terminology and set of concepts for
 identification and resolution of portability and interoperability issues.

 The POSIX Open System Environment is defined in five parts:

     (1)  General requirements are identified that apply to the POSIX OSE
          as a whole in 3.1.

     (2)  A reference model is developed that unambiguously identifies the
          system under consideration for purposes of specification.  The
          POSIX OSE reference model described in 3.2 defines system
          elements to identify interfaces across which service
          requirements should be satisfied.  The elements are chosen to
          expose those interfaces that are significant to the profile
          writer or user.

     (3)  Using the interfaces identified in the reference models, each
          subclause of Section 4 categorizes and describes the basic
          services available to users across each interface.  The services
          are defined in a generic way, based on the reference model, user
          requirements, and current industry practice, rather than any
          given implementation.

          Definition of the service requirements is not constrained by the
          availability of standards.  Service requirements that are not
          currently satisfied via standards are discussed in either the
          Emerging Standards subclause, or under Gaps.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3 POSIX Open System Environment                                        15






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          Each clause of Section 4 begins with a more detailed and
          specialized version of the reference model to provide a context
          for service specification.  After defining the interfaces and
          services, each of the Section 4 clauses concludes with a
          discussion of standards that are related to the services.

     (4)  Section 5 discusses issues and requirements that directly affect
          all of the service categories, such as internationalization,
          security, and administration.

     (5)  Section 6 provides guidelines for creating profiles that address
          various application domains.  This is a brief description of how
          the reference model and services are applied to a variety of
          existing types of systems.  Section 7 describes current POSIX
          profiles and profiling activities.

                                                                            e

 Definition of the service requirements is not constrained by the
 availability of standards.  Services requirements that are not currently
 satisfied via standards are discussed in either the Emerging Standards
 subclause, or under Gaps.



 3.1  POSIX Open System Environment - General Requirements

 The POSIX Open System Environment should satisfy the requirements in the
 following list:

     (1)  Application Portability at the Source Code Level

          The POSIX OSE shall enable application software portability at
          the source code level.

          Rationale:  Comprehensive and consistent source code level
          service specifications allow porting of applications among
          processors (ideally without modification).  Binary portability
          requires too tight a coupling with the processor implementation.

     (2)  System Interoperability

          The POSIX OSE shall enable application software and system
          service interoperability.

          Rationale:  Communications services and format specifications
          allow two entities participating in a distributed system to
          exchange and make mutual use of data, including:



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 16                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

           - Homogeneous systems

           - Heterogeneous systems (i.e., a wide variety of
             hardware/software platforms)

           - POSIX-OSE-based and non-OSE-based systems

     (3)  User Portability

          The POSIX OSE shall enable human users to operate on a wide
          range of systems without retraining.

          Rationale:  Standard methods and services for supporting
          human/computer interaction are a key aspect of the definition of
          an open system (see Section 2).  Elimination of gratuitous
          differences in the interface that the application platform
          presents to the user via standards is a significant aspect of
          this task.

     (4)  Accommodation of Standards

          The POSIX OSE shall accommodate existing, imminent, and new
          information technology standards.

          Rationale:  If the POSIX OSE were constrained to current
          technology, it would quickly become obsolete.  It would also not
          be capable of providing a complete set of applicable standards
          and profiles, as efforts to-date have not yet provided a full
          suite of applicable standards.  The POSIX OSE must evolve as
          standards emerge and technology changes.

          An inevitable tension exists between establishing fixed
          standards and providing for technology enhancement.  Therefore,
          the POSIX OSE must be sufficiently general to allow for
          technology growth and yet specific enough to act as a guide for
          standards development.

     (5)  Accommodation of New Information System Technology

          The POSIX OSE shall accommodate new Information System
          Technology.

          Rationale:  The POSIX OSE must strive to satisfy the full range
          of the users' functional requirements.  This is undoubtedly a
          requirement that will only be fully realized over time, but it
          reflects the goal of the POSIX OSE.

     (6)  Application Platform Scalability



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.1 POSIX Open System Environment - General Requirements               17






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          The POSIX OSE shall be scalable to platforms of varying power
          and implementation complexity.

          Rationale:  This reflects the realities of the potential users
          of the POSIX OSE.  This requirement affects individual standards
          as well as the conditions under which various of the standards
          can or should be combined into profiles.

          For example, where similar services are provided by both
          workstation type application platforms and supercomputers, the
          same standards should be applied to each if possible.  This
          would enable a greater degree of portability across these
          specialized implementations of the application platform.

     (7)  Distributed System Scalability

          The POSIX OSE shall provide for distributed system scalability.

          Rationale:  The number of distributed system components
          connected should not be limited by any structural aspects of the
          POSIX OSE.

          For example, in the area of network services, the OSE standards
          should be such that it is possible to construct profiles (and
          therefore systems) in which remote and local operation and
          utilization of information system resources are
          indistinguishable, with the exception of unavoidable message
          transit delay.  In other words, it should be possible for
          applications to be unaware of whether the application platform
          on which they are executing is local or distributed and that
          lack of awareness should not affect their proper operation.

     (8)  Implementation Transparency

          The POSIX OSE shall provide implementation technology
          transparency.

          Rationale:  The mechanism for implementation of services is not
          visible to the service user; i.e., only the service is visible
          to the service user.

     (9)  User's Functional Requirements

          The POSIX OSE shall reflect the full scope of the user's
          functional requirements, within the context of the other
          requirements above.

          Rationale:  The POSIX OSE will provide the context within which
          application software portability can be addressed and it is the


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 18                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          set of user's functional requirements that defines the scope of
          transportable service needs.



 3.2  POSIX Open System Environment Reference Model

 The POSIX OSE is based on a reference model with the full information
 system as its scope.  As such, it spans the gap between requirement
 specification and the design of any specific information system.  The
 reference model provides a set of conventions and concepts, mutually
 agreed upon between the information system user and provider communities.
 This common understanding is key to achieving application software
 portability, system interoperability, and may encourage software reuse.
 It will certainly allow for more compact and correct procurement
 specifications.

 The definition of this reference model is an engineering and management
 task and not a scientific one.  There are many possible models and, while
 it might be interesting to contemplate an optimal one, a reference model
 that satisfies the requirements is all that is necessary.

 An information system reference model must satisfy conflicting
 requirements similar to those encountered in traditional architectural
 disciplines.  The reference model must be structured enough to encourage
 the generation and use of standards and standard components.  Yet it must
 also be flexible enough to accommodate tailored and special purpose
 components necessary to meet realworld needs.

 The POSIX OSE Reference Model is a set of concepts, interfaces, entities,
 and diagrams that provides a basis for specification of standards.  The
 POSIX OSE Reference Model will provide guidance and direction for future
 standardization and integration efforts.  In order for the POSIX OSE to
 evolve and mature, it will be necessary for the reference model to
 provide insights into those services and capabilities for which standards
 do not currently exist and for which appropriate standardization
 activities cannot be identified.

 The POSIX OSE Reference Model is described from the user perspective;
 i.e., the reference model records the application platform user's
 perception (mental model) of the overall large distributed system used to
 support the user enterprise.  This point of view will assure that the:

     - Information technology users will have the proper services to meet
       their requirements, and

     - Information technology vendor implementations will not be
       constrained unnecessarily.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.2 POSIX Open System Environment Reference Model                      19






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________

























 _________________________________________________________________________
                 Figure 3-1  -  POSIX OSE Reference Model


 Figure 3-1 depicts the basic elements of the POSIX Open System
 Environment Reference Model.  These include three entities (Application
 Software, Application Platform, and External Environment) and two
 interfaces between them, identified as the Application Program Interface
 (API) and the External Environment Interface (EEI).  The application
 platform provides API and EEI services across the associated interfaces.

 This model has been generalized to such a degree that it can accommodate
 a wide variety of general and special purpose systems.  More detailed
 requirements exist for each service category described in Section 4.  The
 service specification has been defined to be robust and flexible enough
 to allow subsets or extensions for each category as needed.  As a result,
 the POSIX OSE reference model is able to accommodate a variety of
 architectures and standardization approaches.  It should be possible to
 show where any relevant standard fits within the reference model.

 Standards (in the sense of formally adopted consensus specifications)
 address only interfaces between entities, as well as services and
 supporting formats offered across those interfaces.  The interface


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 20                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 specification defines a convention adopted to represent the function
 offered across the interface in both directions.  Note that no set of
 standards can, by itself, assure portability of specific applications.
 Applications must be properly engineered with an explicit portability
 objective in order to achieve it.

 The Reference Model is not a layered model.  The application platform
 provides services to a variety of users across both platform interfaces.
 A human being invokes the platform services at the External Environment
 Interface.  If an application developer is the application platform user,
 the services offered at the application program interface (API) are
 invoked at the source code level.

 All of these features may be available locally or remotely if the system
 is connected to a larger distributed system.  All other resources and
 objects can be conceptualized as being contained within the application
 platform.

 Note that the actual implementation of any given system element may
 differ greatly from the reference model presented.  The intention is to
 define a conceptual reference model that the widespread design,
 implementation, and integration communities may assume in executing their
 activities.  Partitioning of function for purposes of discussion or
 specification does not imply or endorse similar partitioning for design
 or implementation.


 3.2.1  Reference Model Entities and Elements

 Figure 3-2 expands Figure 3-1 to identify elements of the Reference Model
 entities.  For the purposes of this discussion, the term ``entities''
 will be used when discussing the classification of items (i.e.,
 ``things'') related to application portability.  The term ``component''
 will only be used when an entity is further decomposed into constituent
 parts.  The application software entity is the only entity that is
 decomposed into components.

 Application Software is defined (see 2.2.2.4) as software specific to an
 application.  It is composed of:

     - Programs (source code, command/script files, etc.)

     - Data (user data, application parameters, screen definitions, etc.),
       and

     - Documentation (online documentation only; hardcopy not included).

 An application program is represented by source code, produced according
 to a specific programming language and a set of language bindings (i.e.,


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.2 POSIX Open System Environment Reference Model                      21






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________

























 _________________________________________________________________________
            Figure 3-2  -  POSIX OSE Reference Model - Entities


 API specifications) for the required services.  These specifications may
 be public standards or other open specifications.

 An application program may be divided into two parts:

     - An _i_n_v_a_r_i_a_n_t portion of source code, requiring no change when
       ported, and

     - A _v_a_r_i_a_n_t portion of source code, which requires changes when
       ported.

 The objective of any effective application software portability method
 should be to minimize the ``variant'' portion of the application software
 via creation and use of API standards.  This would ideally allow
 application software components to be moved to a different (but
 portability-standard compliant) system and run without source code
 modification.  However, since standards exist for which strictly
 conforming application software requires modification (e.g., memory
 requirements, processor-specific COBOL statements), this can only be


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 22                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 approximated.

 Separate but related standards may be required to support the portability
 of each of the elements listed above.  Examples of application software
 are the familiar word-processing, spreadsheet, or accounting packages, as
 developed by the consumer or a commercial application software developer.
 Each of these packages appears as an application software entity when
 executed on an application platform.

 One or more applications may run on a given application platform
 simultaneously, as represented by the boxes at the top of Figure 3-2.
 Each application can be thought of as an independent application entity,
 communicating and synchronizing with other applications, if necessary,
 via a variety of communications mechanisms.

 The Application Platform is defined (see 2.2.2.2) as the set of resources
 that support the services on which an application or application software
 will run.  It provides services at its interfaces that, as much as
 possible, make the implementation-specific characteristics of the
 platform transparent to the application software.

 In order to assure system integrity and consistency, application software
 entities competing for application platform resources must access all
 resources via service requests across the API.  Examples of application
 platform elements could include an operating system kernel, a realtime
 monitor program, and all hardware and peripheral drivers.

 The application platform concept does not imply or constrain any specific
 implementation beyond the basic requirement to supply services at the
 interfaces.  For example, the platform might be a single processor shared
 by a group of applications, or it might be a large distributed system
 with each application dedicated to a single processor.  (See 3.2.4.)

 The application platform for systems built to the POSIX OSE will differ
 greatly depending upon the requirements of the system and its intended
 use.  It is expected that application platforms defined to be consistent
 with the POSIX OSE will not necessarily provide all the features
 discussed here, but will use tailored subsets for a particular set of
 application software.

 The External Environment contains the external entities with which the
 application platform exchanges information.  These entities are
 classified into the general categories of human users, information
 interchange entities, and communications entities.

 Human users are not further classified, but are treated as an abstract,
 or average, person.  Information interchange entities include removable
 disk packs, floppy disks, and security badges.  Communications entities
 include phone lines, local area networks, and packet switching equipment


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.2 POSIX Open System Environment Reference Model                      23






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 3.2.2  Reference Model Interfaces

 _________________________________________________________________________



























 _________________________________________________________________________
           Figure 3-3  -  POSIX OSE Reference Model - Interfaces


 Figure 3-3 expands Figure 3-1 to identify the services available at the
 reference model interfaces.

 Between these three classes of entities there are two types of interface
 where standards and other open system specifications are required to
 enable application software portability and interoperability.  These two
 interface types are labeled as the Application Program Interface (API)
 and the External Environment Interface (EEI).

 3.2.2.1  External Environment Interface (EEI)

 The External Environment Interface is defined (see 2.2.2.8) as the
 interface between the application platform and the external environment
 across which information is exchanged.  It is defined primarily in
 support of system and application software interoperability.  User and


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 24                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 data portability are directly provided by the EEI, but application
 software portability also is indirectly supported by reference to common
 concepts linking specifications at both interfaces.  The services
 available at the EEI comprise:

     - Human/Computer Interaction Services

     - Information Services

     - Communications Services

 The Human/Computer Interaction EEI is the boundary across which physical
 interaction between the human being and the application platform takes
 place.  Examples of this type of interface include CRT displays,
 keyboards, mice, and audio input/output devices.  Standardization at this
 interface will allow users to access the services of compliant systems
 without costly retraining.

 The Information Services EEI defines a boundary across which external,
 persistent storage service is provided, where only the format and syntax
 is required to be specified for data portability and interoperability.

 The Communications Services EEI provides access to services for
 interaction between internal application software entities and
 application platform external entities, such as application software
 entities on other application platforms, external data transport
 facilities, and devices.  The services provided are those where protocol
 state, syntax, and format all must be standardized for application
 interoperability.

 3.2.2.2  Application Program Interface (API)

 The Application Program Interface (API) is defined (see 2.2.2.3) as the
 interface between the application software and the application platform
 across which all services are provided.  It is defined primarily in
 support of application portability, but system and application software
 interoperability also are supported via the communications services API.

 The POSIX OSE API is a combination of a number of standards-based
 interfaces.  It can be thought of as a bookshelf containing several
 standards-based APIs, with each API a separate book on the bookshelf.

 The POSIX OSE API specifies a complete interface between the application
 software and the underlying application platform, and may be divided into
 the following parts:

     - System Services API                                                  e




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.2 POSIX Open System Environment Reference Model                      25






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Communications Services API                                          e

     - Information Services API                                             e

     - Human/Computer Interaction Services API                              e

 The last three APIs listed are required to provide the application         e
 software with access to services associated with each of the external
 environment entities.

 The first API is required to provide access to services associated with    e
 the application platform internal resources, identified as the System
 Services API.  This interface may be divided into two types of
 specifications; i.e., Language Service and System Services API
 specifications.

 Definitions of services at the API take the form of programming-language
 specifications, language-independent service specifications, and language
 bindings for the service specifications.  These specifications may be
 described as follows:

     (1)  Those traditionally associated with the language specifications,
          such as program control (if ... then ... else), math functions,
          string manipulation, etc., defined as _t_h_e _p_r_o_g_r_a_m_m_i_n_g _l_a_n_g_u_a_g_e
          _A_P_I, and

     (2)  Services provided by the underlying application platform defined
          independent of language, such as interprocess communications,
          interobject messages, access to the user interface, and data
          storage.  Specifications of for these services are defined
          independently of any programming language, and are identified as
          _l_a_n_g_u_a_g_e-_i_n_d_e_p_e_n_d_e_n_t _s_e_r_v_i_c_e _s_p_e_c_i_f_i_c_a_t_i_o_n_s.

     (3)  The language-independent service specifications are translated
          into language-specific specifications used by programmers in
          writing applications.  These specifications provide access to
          the services using methods consistent with a specific
          programming language.  Such language-specific specifications are
          called _l_a_n_g_u_a_g_e-_b_i_n_d_i_n_g _A_P_I_s.

 Creation of a _l_a_n_g_u_a_g_e-_i_n_d_e_p_e_n_d_e_n_t _s_e_r_v_i_c_e _s_p_e_c_i_f_i_c_a_t_i_o_n facilitates the
 management and development of consistent language binding standards.  The
 language-binding specifications are used directly by programmers and
 application platform suppliers in implementing application software and
 platforms.

 The ``programming language''/``language binding'' dichotomy may be a
 result of the way Information Technology standards are currently
 developed.  Programming language specifications are developed with the


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 26                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 goal of being ``system independent'' (e.g., C, COBOL, FORTRAN, etc.).
 Language Binding specifications (e.g., POSIX.1 {2}, MOSI, etc.) are being
 translated into ``language-independent'' specifications, with one or more
 bindings for specific languages.


 3.2.3  EEI-API Service Relationships

 The relationships between similarly named services provided at the API
 and the EEI are not simple one-to-one relationships.  For example, a data
 storage service interface may provide an application with transparent
 access to a remote file via network services.  In this case, the
 completion of the data storage service provided at the API is dependent
 upon, and can be thought of as having been ``translated'' into,
 communication services provided at the EEI.

 Fortunately, it is not essential for the purpose of satisfying the
 requirements of the POSIX OSE to specify these relationships in detail.
 In fact, a detailed definition could unnecessarily constrain the
 implementation.  A given implementation of the application platform will
 define the relationship between the API and EEI in different ways.


 3.2.4  POSIX OSE-Based Distributed Systems

 In a distributed environment, multiple application platforms may interact
 by way of a network external to the platforms, but connected to them via
 the communications EEI, as in Figure 3-4.  For an application software
 entity to gain access to the EEI services, communications services are
 requested at the API.  The implementation of the application platform
 translates these API requests into appropriate action at the EEI.

 Communication occurs between application platforms via external entities
 that implement the data transport function.  These can use a wide variety
 of implementation methods and protocols, providing access to distributed
 data and services via the network.

 Distributed Systems are manifest in this model primarily through the use
 of the distributed system network services API.  As can be seen in
 Figure 3-5, distributed systems are a refinement of the POSIX Network
 Environment Model shown in Figure 4-3.  As such, a perceived Application
 Platform may in fact be comprised of several (or many) individual
 application platforms.  However, in the distributed environment, they
 operate and are viewed as a single entity by the using applications.
 Within this extended application platform are the embedded network
 services necessary for the elements of a distributed environment to
 function.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.2 POSIX Open System Environment Reference Model                      27






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________



















 _________________________________________________________________________
      Figure 3-4  -  POSIX OSE Reference Model - Distributed Systems


 Within the distributed environment, network access between the platforms
 that make up the ``perceived'' application platform are handled using the
 Distributed Systems Network Services APIs.  Network services for access
 between ``perceived'' application platforms will use the Network Services
 EEI between the platforms.



 3.3  POSIX Open System Environment Services

 This guide defines a uniform set of standard services provided to users
 of application platforms in support of POSIX objectives of application
 portability and system interoperability.  These services are available to
 users across specified interfaces keyed to the POSIX reference model
 defined in 3.2.

 The POSIX OSE services are divided into categories described by the
 clauses in Section 4.  Each category begins by defining a more detailed
 and specialized version of the OSE reference model (see 3.2) to provide
 context for service specification.  Services and associated standards are
 then defined for each category.  Finally, POSIX OSE Cross-Category
 Services affecting each category are discussed.

 The service descriptions for each category are intended to be complete
 and not merely representative.  Further refinement through successive


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 28                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________























 _________________________________________________________________________
            Figure 3-5  -  Distributed System Environment Model


 releases of this document will lead to a complete specification.



 3.4  POSIX Open System Environment Standards

 The identification of a complete, consistent suite of standards for the
 POSIX OSE will, by necessity, draw from many forums.  One of the criteria
 for judging completeness is the satisfaction of the full range of
 services required by the application platform user.  The factors used to
 select standards will be described followed by the selection precedence.

 Note that while the services are stated with a clear partitioning in
 mind, the standards reflect the current partitioning.  These standards
 were created within disparate organizations and projects, which were in
 many cases carried out in isolation from the others.  As a result,
 mapping of services to standards is not a simple relationship.






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.4 POSIX Open System Environment Standards                            29






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 3.4.1  Factors in Standards Selection

 The selection criteria for standards to be included in the POSIX OSE are
 based upon four concepts.  Those concepts are Those concepts are
 openness, Stage of Completion, stability, Geographic Scope of Consensus,
 Functional Scope Addressed within this guide, Consistency with
 POSIX.1 {2}, and Availability for Unencumbered Implementation.

     (1)  Openness

          Standards development organizations can differ from one another
          by virtue of their ``openness.''  That is, some standards
          development bodies utilize an open forum for the development of
          standards while other bodies use a closed forum.  The result is
          a varying degree of consensus in the technical content of the
          standards across development bodies.

          As a general rule, standards developed by accredited standards
          development organizations (all of which use an open forum) are
          preferred over those standards developed by bodies using a
          closed forum.

     (2)  Stage of Completion

          Another factor involved in the selection of standards for
          inclusion in the POSIX OSE is ``stage of completion.''  That is,
          there is a standards development life cycle process whose
          effects need to be taken into account.  Most standards follow a
          sequence from approved development, through draft, and on to
          approved standard.

          As a general rule, where choices were made among standards, the
          more complete standards were favored.

     (3)  Stability

          A third factor in determining which standards are included in
          the POSIX OSE is stability.  This factor refers to anticipated
          change in the standard over time.  This change may expand or
          contract the technical coverage of the standard.

          As a general rule the more stable standards are preferred over
          those subject to change.

     (4)  Geographic Scope of Consensus

          There are differences among standards development bodies with
          respect to the scope of their geographic consensus.  Some among
          those bodies are formal standards bodies (i.e., accredited as


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 30                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          standards developers by a recognized body).  It is typical for
          those bodies to be authorized to develop standards for a
          particular technical topic and have their standards applicable
          to some defined geographic area.  Formal standards development
          bodies are typically empowered to develop standards for either
          international, regional or national standards coverage.

          The general rule applied in the selection of standards for
          inclusion in the POSIX Open System Environment is to select
          standards developed by those bodies that have the greatest scope
          of coverage.  This results in a precedence for standards
          selection of international, followed by regional, followed by
          national body developed standards.

     (5)  Functional Scope Addressed within this guide

          A specification is listed only if it addresses some service
          requirement listed in this guide.  Standards and/or
          specifications listed are not, however, limited to one per set
          of services.

     (6)  Consistency with POSIX.1 {2}

          Standards listed in this guide are suitable for inclusion in a
          profile with POSIX.1 {2}, and do not contradict that standard in
          any way.

     (7)  Availability for Unencumbered Implementation

          A standard or specification is listed only if it is available
          for implementation to the specification and distribution of that
          implementation is unencumbered.  The specification qualifies for
          inclusion in the guide even if the document itself is a salable
          item.


 3.4.2  Selection Precedence

 The list below shows the precedence of standards and specifications as
 used for inclusion in the POSIX OSE.  The order from top to bottom is
 from most to least preferred.

     (1)  Approved standards developed by accredited international bodies

     (2)  Approved standards developed by accredited regional bodies

     (3)  Approved standards developed by accredited national bodies




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.4 POSIX Open System Environment Standards                            31






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     (4)  Draft standards developed by accredited international bodies

     (5)  Draft standards developed by accredited regional bodies

     (6)  Draft standards developed by accredited national bodies.

     (7)  Recognized de facto standards and specifications developed by
          nonaccredited bodies using an open forum

     (8)  Approved standards and specifications developed by nonaccredited
          international standards bodies using a closed forum

     (9)  Approved standards and specifications developed by nonaccredited
          national standards bodies using a closed forum.

 Standards projects for which there is no draft or approved standard are
 never selected for inclusion in the POSIX OSE.

 Only the highest precedence specification is listed or discussed in the    e
 main text.                                                                 e

 This guide only cites government and de facto standards and
 specifications in discussion of gaps in available standards.



 3.5  POSIX Open System Environment Profiles

 The results of Open System specification projects are collected into an
 expanding set of ``Base Standards,'' addressing a growing subset of
 functional requirements.

 Profile projects then select among these base standards to create a
 tailored, consistent set of standards addressing a more specific type (or
 instance) of system or set of application software.  Profiles satisfy the
 requirements of application ``domains'' such as office or industrial
 automation, transaction processing, or realtime control systems.

 This framework provides a way to characterize the functionality of
 profile activities.  The current OSI profiles tend to focus strictly on
 the communications EEI.  Other profiles might focus on a single component
 or span multiple interface types.









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 32                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 3.6  Application Platform Implementation Considerations

 Profile writers need to be aware that in an open system environment, the
 application platform can be decomposed into independently procurable
 components.  While standards are interface specifications, and as such
 are independent of implementation, there are aspects of platform
 implementation or construction that may affect the specification of
 standards, and that profile writers may want to address.

 For each case, the portion of the application platform that implements
 any particular independently procurable service is described as the
 service component.  Figure 3-6 shows an application platform made up of
 several service components.  If components interact, the specification of
 the interface between service components within the application platform
 may be standardized or nonstandard (including proprietary).

 _________________________________________________________________________



















 _________________________________________________________________________
             Figure 3-6  -  Service Components and Interfaces


 An intercomponent interface is labeled in Figure 3-6 as ``System Internal
 Interface'' because it may be used to assemble an application platform
 from multiple components.  Figure 3-6 shows how a System Internal
 Interface is shown in the reference model.

 A standards-based SII between the application platform service components
 addresses portability and interoperability of the application platform
 service components, not portability and interoperability of application
 software and systems.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.6 Application Platform Implementation Considerations                 33






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Development of an SII would also require a consensus to emerge on the
 ``best'' design and implementation of system software/hardware.  Very
 little consensus has developed on the partitioning of the platform into
 components and consequent allocation of function to each.  In fact, this
 aspect of system design has been in a constant and accelerating state of
 innovation for decades.  One of the major objectives of the API is to
 provide a more stable interface that decouples application software from
 the constantly changing platform.  This enables the migration of
 application software to platforms based on constantly upgraded
 technology.  (See 3.1 ``Accommodation of New Information System
 Technology''.)

 The relationship and services exchanged among the components may be quite
 complex and varied in different implementations.  This complexity and
 variety would, of necessity, be reflected in an SII.  It would not,
 however, be visible to the application software at the API, since one of
 the major objectives of the API is to hide this complexity.  (See 3.1
 ``Implementation Transparency''.)

 Since SII specifications

     - do not affect application portability and interoperability, and

     - do not affect specification of the API and EEI, and

     - are primarily driven by specific implementations of the application
       platform,

 SII specification is beyond the scope of this guide.

 Specification of SII in this guide would represent an unnecessary
 constraint on the implementation of the application platform, and are
 unnecessary for the specification of the API and EEI.

 There are a number of ways which the Application Platform can be divided
 into separate service components.  The main decomposition methods are
 division, layering, and redirection.  These methods are indistinguishable
 to the application software and external entities, in that they all
 interface to the application platform via the API and EEI, respectively.
 They assume a starting base application platform, which provides a subset
 of the required services.


 3.6.1  Subdivision

 In this commonly used method, the application platform is simply
 subdivided into a base and one or more service components.  See
 Figure 3-7.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 34                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________














 _________________________________________________________________________
     Figure 3-7  -  Application Platform Implementation - Subdivision


 One possible implementation of this is to link the appropriate service
 modules directly into the system kernel.

 The internal interfaces used in this method are normally proprietary, and
 hence normally imply that both components will come from the same vendor.

 In this case the Application Platform and the Application Platform Base
 are the same entity.


 3.6.2  Layering

 In layering, the service is interposed as a layer between the application
 software and the base application platform.  See Figure 3-8.

 This is the most common method of supplying a service component that is
 independent of the base.  One possible implementation is to provide the
 service component as a set of library routines.

 Whether the interface between the service layer and the base application
 platform conforms to any standards affects the portability of the service
 component.  Note that specifying a standard API for this interface
 guarantees only that this component will be portable at the source level.









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.6 Application Platform Implementation Considerations                 35






 P1003.0/D14

 _________________________________________________________________________
















 _________________________________________________________________________
      Figure 3-8  -  Application Platform Decomposition II - Layering

 _________________________________________________________________________
















 _________________________________________________________________________
    Figure 3-9  -  Application Platform Decomposition III - Redirection


 3.6.3  Redirection

 Redirection allows a service component to ask the base application
 platform to redirect all requests for that type of service to the service
 component.  See Figure 3-9.  Possible examples of such services are
 device drivers, network protocol handlers, and database engines.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 36                                        3 POSIX Open System Environment






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 In actual implementation, the service component may or may not be a
 separate process.  Possible implementations are:  dynamically loadable
 kernel modules, library routines layered over IPC, and lightweight kernel
 processes.

 Note that there are three interfaces.  The application software normally
 sees a complete, standard API to the base.  The service component has two
 interfaces--one to effect the redirection, and one to provide base
 services to the service application software entity.  Considerations for
 portability discussed under Layering also apply here.

 Note also that no POSIX standardization activity currently exists for the
 redirection interface.






































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 3.6 Application Platform Implementation Considerations                 37








































































                                                               P1003.0/D14








             Section 4: POSIX Open System Environment Services



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _F_r_i_t_z _S_c_h_u_l_z

 This section describes the services required in support of the objectives
 identified in this guide.  The services are grouped in major categories
 defined in Section 3, with more detailed breakdowns within each category
 as appropriate.  These categories are:

    System Services                                                         e

          4.1   Language Services

          4.2   System Services

    Communications Services

          4.3   Network Services

    Information Services

          4.4   Database Services

          4.5   Data Interchange Services

          4.6   Transaction Processing Services                             e

    Human-Computer Interaction Services

          4.7   Windowing System Services

          4.8   Graphic Services

          4.9   Character-Based User Interface Services

          4.10  User Command Interface Services

                                                                            e




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4 POSIX Open System Environment Services                               39






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Criteria used to partition services are outlined in 3.2, and discussed at
 the beginning of each clause.  The discussion for each of the service
 category subclauses follows the same outline, and is as follows:

    4._n.1    Overview and Rationale                                         e

             This text gives an overview of the service category and        e
             rationale for its use as a category.                           e

    4._n.2    Scope                                                          e

             This text introduces the scope of this service category, and
             the criteria used to identify the services within it.

    4._n.3    Reference Model

             This subclause builds on the model of clause 3.2 and gives
             additional detail related to the interfaces and services
             discussed there.  An optional subclause may discuss
             implementation considerations, similar to the discussion of
             3.6.

    4._n.4    Service Requirements

             This text provides the definition of service requirements
             within the scope described in 4._n.2.

    4._n.5    Standards, Specifications, and Gaps

             A table lists the standards and specifications available to
             meet the service requirements listed in 4._n.4.  This is
             followed by a brief discussion of services for which
             standards are not available.  The list of standards in the     e
             table is comprehensive for the area covered by the 4._n.4       e
             requirements; there are no applicable standards or emerging    e
             standards excluded from the POSIX OSE.  Within the table, the  e
             Type column refers to the status of the requirement:           e

                S  A current standard                                       e

                E  An emerging standard                                     e

                G  A requirement not satified by a formal standard (gap)    e

    4._n.5.1  Current Standards

             The following subclauses cite existing specifications that
             have been approved as standards by accredited standards
             bodies, in the order of precedence identified in 3.4.2.  When


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 40                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

             service requirements are satisfied at a higher precedence
             level, specifications at a lower level are not listed.

    4._n.5.2  Emerging Standards

             The following subclauses provide an alphabetized list of       e
             specifications and/or activities that address the functional   e
             areas within the 4._n section, but which have not yet been
             completed.  Where a group or activity is cited, the charter
             of the group may address the functionality, but it is
             possible that a draft may not be available.  Only those
             services not currently addressed by existing standards are to
             be discussed in this subclause.  It is expected that
             documents will migrate from 4._n.5.2 to 4._n.5.1 as they
             complete the consensus process.

    4._n.5.3  Gaps in Available Standards

             This subclause identifies those service requirements that
             have not been satisfied by existing or emerging standards.
             If all service requirements in this category have been met by
             existing or emerging standards, this subclause will be empty.
             Text in this subclause will be minimal.

    4._n.5.3.1 Public Specifications

             This subclause lists any specification outside of the formal
             standards community that is available to anyone (e.g., no
             membership required) for implementation and distribution
             (including sale) without restriction, including all
             government and de facto standards.

    4._n.5.3.2 Unsatisfied Service Requirements

             This subclause lists the services for which no specification
             has been cited in this guide.  Products may be cited here to
             illustrate capabilities that are not addressed by standards.

    4._n.6    POSIX OSE Cross-Category Services

             This subclause contains any discussion of the Cross-Category
             Services in Section 5 that is specific to subclause 4._n.

    4._n.7    Related Standards

             This subclause is optional and may identify interdependencies
             among standards that should be taken into account when
             selecting among them.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4 POSIX Open System Environment Services                               41






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

    4._n.8    Open Issues

             This subclause is optional and may identify issues under
             discussion in the open systems community.

 Specification of performance metrics is not within the scope of this       e
 guide.                                                                     e












































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 42                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.1  Language Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _D_o_n _F_o_l_l_a_n_d


 _4._1._1  Overview and Rationale

 While a consistent interface to the operating system is essential for
 applications portability, the application will have been developed using
 language and system development tools that, in turn, require support by
 standards to achieve source code portability.

 Those responsible for system or software development will wish to write
 programs in code supported by an international standard and compile the
 code using a compiler that has a certificate of conformance issued by an
 accredited test center.  Noncompliant extensions must be avoided if
 applications portability is to be maintained.  Compilers should identify
 nonstandard-compliant code.

 The languages that have been identified in this document are those seen
 to be in most popular use today for software development.  The POSIX.2
 shell command language is discussed in 4.10.  The standards identified
 are the most widely recognized today, with significant use in the
 Information Technology industry on a broad range of processors, or where
 a large installed base of a particular version is known to exist.


 4.1.2  Scope

 The services described in this clause cover the most widely used third-
 generation computer languages in use today for the development of
 applications; i.e., the languages used to write application programs.
 Fourth-generation languages are not currently addressed in this guide.
 In order for a program to address an API to the services described in
 other clauses of this guide, an appropriate language binding to that
 interface is required.  References to those bindings will be found in the
 clause describing the relevant service.


 4.1.3  Reference Model

 This subclause identifies the entities and interfaces supporting language
 services.  The reference model based on the reference model in Figure 3-1
 is illustrated in Figure 4-1, but because the language services directly
 support the binding of the applications to the API, there is no EEI.
 However, the EEI is shown in Figure 4-1 for consistency.

 At the simplistic level, the programmer developing an application that
 requires only basic operating system services will use a compiler that


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.1 Language Services                                                  43






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________
















 _________________________________________________________________________
              Figure 4-1  -  Language Service Reference Model


 meets both the fundamental language standard (e.g., ISO 1989: 1985 for
 COBOL, ISO 1359: 1990 for Fortran) and the binding established for the
 relevant system calls in POSIX.1 {2}.

 As identified in 4.6, an application program may also require database
 services that will be provided by the Database Manager API.  The database
 vendor will offer an API to meet the requirements for the popular
 programming languages.

 In a POSIX Open System Environment the intention is that support is
 provided for all languages identified in 4.1.4.


 4.1.4  Service Requirements

 Programming language services provide the basic syntax and semantic
 definition for use by a software developer to describe the desired
 application software function.  While most clauses in this guide provide
 a comprehensive list of services, in the case of languages many services
 are a unique function of the language specification.  Rather than extend
 the size of this guide, the detail is more appropriately found in the
 relevant language manuals and supporting standards.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 44                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.1.4.1  Application Program Services

 Programmers require the ability to write and execute a program in the      e
 language of their choice.  The selection of a particular programming
 language for the development of an application may depend on a variety of
 factors, including the capability to provide some of the functions listed
 here:

     - Arithmetic operation

     - Code structure

     - Data definition

     - Data representation

     - Error handling

     - I/O operations

     - Mathematical functions

     - Program control logic

 The programming languages identified in this clause are:

       Ada
       APL
       BASIC
       C
       C++
       COBOL
       Common LISP
       FORTRAN
       Pascal
       PL/1
       Prolog

 As well as making reference to the relevant language standard, where a
 programmer requires to call other services, e.g., seeks access to
 graphics kernel system, it will be necessary to refer to the relevant
 language binding to those services.  Language bindings are identified in
 the Standards subclause, 4._n.10, of each service clause in Chapter 4.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.1 Language Services                                                  45






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.1.4.1.1  Ada

 Ada is a procedural language based on the Pascal programming language.
 It is capable of processing both numerical and textual data and has the
 key attributes of:

     - Strong data typing

     - Data abstraction

     - Structured constructs

     - Multitasking

     - Concurrent processing

 Although Ada was developed initially for military purposes, it is
 considered suitable for a variety of business and industrial
 applications.

 4.1.4.1.2  APL

 APL is a language and interactive programming environment oriented around
 multidimensional arrays of characters and numbers.  It uses an extremely
 compact notation based on powerful primitive functions and function-
 combining operators.  Revisions to the language are in preparation to
 permit single array elements to contain arrays.

 4.1.4.1.3  BASIC

 BASIC is an interactive and procedural language with some similarity to
 FORTRAN.  It is readily learned by non-computer-literate individuals.
 Commonly used for educational purposes, it has also been adopted in a
 variety of business and commercial applications running on small business
 systems.  BASIC offers:

     - Conversational statements

     - Free style input

     - Segmentation of complex statements

     - Six significant digits of accuracy

     - Mathematical functions






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 46                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.1.4.1.4  C

 C is a general purpose procedural language that was developed for the
 UNIX operating system.  It offers the control and data structure of a
 high-level language and the efficiency of primitive operators that have
 made it very suitable for system programming.

 4.1.4.1.5  C++

 C++ has evolved as a superset of C and may be viewed as a procedural
 language, while at the same time offering the capability for object-
 oriented programming.  The concept of an object-oriented language is to
 define data objects that include sets of operations to manipulate the
 data, and so direct these objects to apply the necessary operations which
 comprise the application.

 4.1.4.1.6  COBOL

 COBOL is a procedural language designed originally to meet the needs of
 business.  It permits use of natural words and phrases, enabling the
 language to be adopted by non-technical writers with a basic appreciation
 of information processing.  The language offers file organization
 features, variable data length, input/output procedures, and report
 generation.

 4.1.4.1.7  Common LISP

 LISP is an interactive nonprocedural language.  The basic entity is the
 symbolic expression which is either an atomic symbol or a list structure.
 A list is a set of items in a specific order.  Lists can be variable
 length and dynamically adjusted; the items can be of different type.

 4.1.4.1.8  FORTRAN

 Though originally developed for processing scientific problems the
 language is widely used in commercial and educational applications.  It
 is a procedural language whose grammar, symbols, rules, and syntax are
 simple mathematical and English-language conventions.  Its focus is on
 numerical computation, using simple concise statements, operating on
 small amounts of input data and little text.

 4.1.4.1.9  Pascal

 This is a procedural language that is particularly effective in
 structured programming and was designed to help programmers in rapid
 error detection.  It is highly efficient, handling both numerical and
 textual data.  It is considered very suitable for small system
 applications such as typesetting, editorial work, computer aided design
 (CAD), and manufacturing processes.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.1 Language Services                                                  47






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.1.4.1.10  PL/1

 This is a procedural language introduced to offer in one language the
 strengths of both COBOL and FORTRAN; i.e., serving both the business and
 scientific communities.  It has the FORTRAN strength of simple
 statements, coupled with the ability, as in COBOL, to manipulate data and
 organize files.  It is block structured, facilitating good programming
 techniques.

 4.1.4.1.11  Prolog

 This language, like LISP, is nonprocedural and has an emphasis on
 description rather than on action.  It is described as pattern-directed
 role-based programming using definitions of conditions established within
 the program to satisfy a query.  It is of particular value in
 applications of artificial intelligence, for constructing expert or
 knowledge-based systems.

 4.1.4.2  External Environment Interface Services

 Not applicable.

 4.1.4.3  Interapplication Software Entity Services

 Not applicable.

 4.1.4.4  Language Resource Management Services

 Not applicable.


 4.1.5  Standards, Specifications, and Gaps

 4.1.5.1  Current Standards                                                 e

 See Table 4-1.                                                             e

 _A_d_a

 ISO 8652: 1987 is the current version of the international standard for
 Ada, which was an endorsement of the ANSI standard 1815A-1983.

 _A_P_L

 ISO 8485 is the current version of the international standard for APL.






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 48                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


                     Table 4-1  -  Language Standards
 __________________________________________________________________________________________________________________________________________________
               Service        Type   Specification   Subclause              e
           ____________________________________________________             e

           Ada                 S     ISO 8652        4.1.5.1     e          ee
           APL                 S     ISO 8485        4.1.5.1     e          ee
           BASIC               S     ISO 6373        4.1.5.1     e          ee
           C                   S     ISO/IEC 9899    4.1.5.1     e          ee
           C++                 E     n/a             4.1.5.2     e          ee
           COBOL               S     ISO 1989        4.1.5.1     e          ee
           Common LISP         G     n/a             4.1.5.1     e          ee
           FORTRAN             S     ISO 1539        4.1.5.3     e          ee
           Pascal              S     ISO 7185        4.1.5.1     e          ee
           PL/1                S     ISO 6160        4.1.5.1     e          ee
           PL/1 (GP Subset)    S     ISO 6522        4.1.5.1     e          ee
           PROLOG              G     n/a             4.1.5.3     e          ee
 __________________________________________________________________________________________________________________________________________________


 _B_A_S_I_C

 ISO 6373: 1984 is the current version of the international standard for
 minimal BASIC.

 _C

 ISO/IEC 9899: 1990 is the current version of the international standard
 for the C language.

 _C_O_B_O_L

 ISO 1989: 1985 is the latest version of the international standard for
 COBOL, which was an endorsement of the ANSI standard X3.23-1985.  An
 Addendum is in process at present entitled ``Intrinsic function module.''

 _F_o_r_t_r_a_n

 ISO 1539: 1990 is the latest revision of the international standard for
 Fortran.

 _P_a_s_c_a_l

 ISO 7185: 1983 is the current version of the international standard for
 Pascal, which was an endorsement of the British standard BS 6192-1982.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.1 Language Services                                                  49






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _P_L_/_1

 ISO 6160: 1979 is the current version of the international standard for
 PL/1, which was an endorsement of the ANSI standard X3.53-1976.  ISO
 6522: 1985 is the current version of the international standard for a
 General Purpose subset of PL/1, which is an endorsement of ANSI standard
 X3.74-1981.  A revision of this standard is at Draft IS stage.

 4.1.5.2  Emerging Standards                                                e

 _B_A_S_I_C                                                                      e

 CD 10279 is a proposal for Full BASIC.                                     e

 _C_+_+                                                                        e

 ISO/IEC JTC 1/SC22/WG21 has a work item for standardizing C++.  This will  e
 be based on the standard under development in ANSI X3J16.                  e

 _P_a_s_c_a_l

 DIS 10206 is a draft international standard for extended Pascal.

                                                                            e

 4.1.5.3  Gaps in Available Standards

 4.1.5.3.1  Standards and Specifications outside the POSIX OSE

 None.                                                                      e

 4.1.5.3.2  Unsatisfied Service Requirements

 There is a requirement for standardization of the following languages:

       C++
       LISP
       Prolog


 4.1.6  OSE Cross-Category Services

 Not applicable.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 50                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.1.7  Related Standards

 Many of the services within the POSIX OSE require APIs with bindings to
 languages identified in this clause; e.g., Graphics, Database.  Reference
 to the particular language binding standard is to be found in the
 relevant service clause.


 4.1.8  Open Issues

 While there are occasional calls for 4GL standards, there has been little
 effort applied so far.







































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.1 Language Services                                                  51






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS




















































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 52                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.2  System Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _P_a_t_r_i_c_i_a _O_b_e_r_n_d_o_r_f


 4.2.1  Overview and Rationale

 This clause describes the system services component of the application
 platform.  It presents a reference model for this component and describes
 the services provided to application software.  Those services are those
 usually considered as part of an operating system or executive and also
 those services that may be provided by system level entities such as
 spoolers and device drivers.  Standards, current and emerging, that
 specify the interface to those system services are also described.

 System services are a key component of the application platform and
 represent the focus of the IEEE effort to produce POSIX base standards.
 A common set of system services provides support for the portability and
 the interoperability of application software.  While other common
 services can aid application reuse, system services are those that are
 common to the largest number of applications.


 4.2.2  Scope

 System services cover those features that users have come to expect from
 operating systems or executives.  They cover the areas of process
 management, file management, input/output, memory management, and print
 spoolers.  Because there is a wide variety of platform users, ranging
 from large general purpose time-shared systems to small time-critical,
 special-purpose systems, services such as timers and clocks, event
 management, logical device drivers, and system
 initialization/reinitialization are included.  Services related to
 distributed systems are also discussed, since application software sees
 these capabilities through the platform.


 4.2.3  Reference Model

 This subclause identifies the entities and interfaces specific to the
 system services of the POSIX OSE.  The reference model presented here is
 consistent with and expands upon the reference model of Section 3.  It
 provides the context for the discussion of System Services in this
 clause.  The basis System Services model is shown in Figure 4-2.

 This clause describes the system services portion of the application
 platform as viewed by a software developer (not necessarily the viewpoint
 of the end user).  This view corresponds to the program design level of
 abstraction.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    53






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________
















 _________________________________________________________________________
              Figure 4-2  -  System Services Reference Model


 The system services API provides the interface between the application
 software and the system services from the source code point of view.  The
 API defines the program designer's means of accessing the functions,
 objects, and services of the system.

 In order for the platform to protect system integrity and ensure system
 database consistency, application software competing for system resources
 must access all system resources via system service requests.  The formal
 definition of these requests (or system calls) defines the system
 services portion of the API.

 All of the system services may be available locally or remotely.  Some of
 the system services may be performed remotely if the system is a
 distributed system with multiple processor nodes.  Such distribution is
 not reflected in Figure 4-2 because it is transparent to users of the
 System Services.

 The platform's device drivers and other software entities are seen as
 being available to an application program via invocation of the system
 services.  Local devices include sensors, effectors, and connections to
 independent computing systems.  The local devices themselves are a part
 of the external entities element of the system services reference model.
 The interfaces used by the application software are the logical device
 interfaces and are part of the system services.  It should be noted that,
 even though the device drivers are represented within the system services
 portion of the application platform and the devices themselves are
 represented within the external entities, there is no unique system
 service interface illustrated at the EEI in Figure 3-3.  This is not an


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 54                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 oversight; such interfaces are not within the scope of this guide.         e

                                                                            e


 4.2.4  Service Requirements

 This subclause identifies those processor-oriented system services
 required to support application portability and system interoperability.
 Subclause 4.2.4.1 describes those system services directly available to
 an application program via the System Services API.  Other processor-
 oriented services are described in 4.2.4.4.  Subclause 4.2.5 identifies
 the applicable standards.

 This subclause describes the major groups of system services that an
 application may require of a platform.  Not all of these services require
 a programming interface; therefore, services are described as either
 explicit or implicit services.  Explicit services are those that can be
 accessed from an application program (via the API) and generally are only
 provided when requested.  Implicit services, on the other hand, are
 services that the platform provides without a direct request.  An example
 of an implicit service is the prevention of one program from writing over
 the memory of another.  An example of an explicit service is a call to a
 system service routine to output the contents of a block of memory to
 some device.

 4.2.4.1  Application Program Interface Services

 This subclause describes the major categories of system services
 available at the System Services API.  These services include:

     - Process Management Services

     - Task Management Services

     - Environment Services

     - Node Internal Communication and Synchronization Services

     - Generalized Input/Output Services

     - File Oriented Services

     - Event, Error, and Exception Management Services

     - Time Services

     - Memory Management Services



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    55






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Logical Naming Services

     - System Initialization, Reinitialization, and Shutdown Services

 4.2.4.1.1  Process Management Services

 These services relate to the creation, management, and deletion of
 processes executing within the scope of an operating system.  These
 processes are distinguished from ``tasks'' via the following
 characteristics:

     - They have a single thread of execution per address space.

     - There is substantial overhead for context switches.

     - Specific attributes are associated only with processes.

 In this context, ``management'' consists of those services that affect
 the execution of a process:

     - Stop and restart execution of a process (e.g., suspend, resume)

     - Modify processor allocation to a process (e.g., priority,
       timeslice)

     - Modify scheduling of the process based on timer (or other) events

     - Protect the process from interruption during critical periods

     - Create a process and make it ready for execution

     - Destroy a process and recover its resources

     - Evaluate a reference to a process

     - Evaluate a connection to a process, where a connection is a logical
       communication path between any two processes

 These services schedule or arbitrate the usage of various resources of
 the OS, particularly the central processing unit (CPU).  The scheduling
 services must be able to queue up requests to use a particular resource.
 This situation is made more complicated by the common need to schedule
 processes to run cyclically at a fixed period.  When a resource becomes
 idle, the scheduler must select one of the ``requesters'' of the resource
 to grant use of the resource.  These services are listed separately
 rather than under the services that use scheduling to emphasize that
 there should be uniformity and consistency of scheduling across the range
 of resources.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 56                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 Typically, there are at least two types of scheduling occurring in an
 operating system:  short-term and long-term.  Long-term schedulers
 determine which possible requesters at a given time may actually request
 a resource.  The short-term scheduler selects from among the active
 ``requesters'' that currently have need of the resource and allocates the
 resource to the selected ``requester.''  For example, if the requesters
 are processes and the resource is the CPU, the long-term scheduler
 manages the movement of processes from inactive (waiting in batch queues
 or in hibernation) to active (in wait or execute).  The short-term
 scheduler, on the other hand, would determine which process should
 execute next on the CPU.  Hybrid services between the two may also be
 available in the operating system.

 When a request for a resource is submitted to the operating system (at
 some local operating system node), it is not always serviced at that
 local node.  The most advantageous way to service the request may result
 in part or all of the work being performed at a different processor node.
 Several reasons may cause this to occur, including load balancing,
 resource availability, computation speedup, hardware preference, and
 software preference.  These services may hide from the application the
 fact that the functionality was being performed at a different node.
 This has the advantage that the code needs to know little about the
 system on which it is running.  Alternately, the services may allow the
 user to specify directly on which logical resource the function should be
 executed.

 The priority scheduling of resources allows the requester to have
 associated with it its importance to use the service.  More complex
 schemes also have a criticalness of the request that is used for graceful
 degradation purposes.  The scheduler(s) will use the priority information
 to arbitrate resource requests and to queue requests in the specific
 order.  A priority scheduler may need to support multilevel queues to
 support proper execution.

 Preemptive schedulers will deallocate a resource from a requester when
 certain events occur.  Usually this is when a requester of a higher
 priority or importance requests the resource or a specified time limit
 for the resource has expired.

 4.2.4.1.2  Task Management Services

 These services relate to the creation, management, and deletion of tasks
 executing within the scope of an operating system.  These tasks are
 distinguished from ``processes'' via the following characteristics:

     - There may be multiple threads of execution per address space.

     - There is low overhead for context switches between threads located
       in the same address space.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    57






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 In this context, ``management'' consists of those services that affect
 the execution of a task:

     - Stop and restart execution of a task (e.g., suspend, resume).

     - Modify processor allocation to a task (e.g., priority, timeslice).

     - Modify scheduling of the task based on timer (or other) events.

     - Protect the task from interruption during critical periods.

     - Create a task and make it ready for execution.

     - Destroy a task.

     - Evaluate a reference to a task.

     - Evaluate a connection to a task, where a connection is a logical
       communication path between any two tasks.

 4.2.4.1.3  Environment Services

 These services provide an application access to a variety of information
 relating to the operating system environment in which the application is
 executing.  The specific characteristics are:

     - Process-specific attributes (process identification, priority,
       stack size, scheduling attributes, status, memory allocation).

     - Task-specific attributes (task identification, priority, scheduling
       attributes, status, memory allocation).

     - Processor-specific attributes (node identification, electronic
       nameplate information).

     - User-specific attributes (user identification and terminal ID, user
       interaction profile).

     - Environment variables (command-line arguments, menu selections).

     - Current time and date

 4.2.4.1.4  Node Internal Communication and Synchronization Services

 One or more applications and application subcomponents may run on a
 processor within an application platform simultaneously.  The
 applications run as independent software entities and communicate among
 themselves via a variety of mechanisms provided or managed by the system
 services (see Figure 3-2).  An important class of system services relates


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 58                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 to the coordination and synchronization of these software entities.  In
 traditional systems, entities execute on a single hardware processor.
 However, it is becoming common to have multiple processors and networked
 processors that place more requirements on the system services to provide
 coordination and synchronization among the many truly concurrent software
 entities.

 When a platform has several software entities executing concurrently, the
 applications need system services so that the entities can be coordinated
 and synchronized with each other.  With respect to applications written
 using concurrency, there are two levels of concurrency that are usually
 seen by the application developer.  The first level of concurrency, task
 level concurrency, is seen when the application is split into multiple
 subcomponents (tasks) that share access to the data and subprograms of
 the application.  Concurrency services at this level concern the relative
 priorities and scheduling of tasks within a single application program
 and their communication with each other.  At the second level of
 concurrency, application level concurrency, a unit is a single
 application including all its subcomponents.  Concurrency services at
 this level concern the relative importance of the individual applications
 competing for and sharing system resources.

 These services are used to communicate among processes, among tasks, and
 among processes and tasks residing on the same node.  The methods
 outlined do not include the network specific services described in 4.3,
 but are limited to methods open to entities executing within the scope of
 a single operating system.  Both synchronous and asynchronous services
 are defined.  The specific services are:

     - Create, delete, open, close, read, and write shared memory.

     - Create, delete, read, and write event flags.

     - Create, delete, set, and wait on semaphores.

     - Create/send and receive signals.

     - Create, delete, open, close, send to, get from, and control message
       queues.

     - Create, delete, send, and receive streams.

 4.2.4.1.5  Generalized Input/Output Services

 These services are used by an application to perform generalized device
 I/O operations.  These operations include synchronous and asynchronous
 operations for device and class specific functions.  Specifically, these
 form the services needed to implement or include logical device drivers
 in a system.  These services are device initialization, device


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    59






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 attachment, asynchronous operation, and error notification.  In addition,
 they include those services that are used to directly access specific
 device capabilities, particularly those services often referred to as
 ``raw I/O.''

 4.2.4.1.6  File Oriented Services

 Mass storage in the form of hierarchy of directories, subdirectories and
 files will be available to an application executing within the
 application platform.  The following paragraphs describe the services
 available for creating, accessing, managing, and deleting these entities
 with mass storage.  Both synchronous and asynchronous services are
 defined.

 _N_a_m_i_n_g__a_n_d__D_i_r_e_c_t_o_r_y__S_e_r_v_i_c_e_s

 These services allow the access of files and directories through logical
 names rather than the actual hardware device naming conventions.  The
 services allow sharing of files at various levels.  For example, the
 services may not allow any shared naming of files and directories between
 systems, or they may allow shared files by explicit naming, or they may
 allow shared files by implicit naming.  The directory services present a
 view or views of the directory structure to the application or target
 system operator.

 _F_i_l_e__M_o_d_i_f_i_c_a_t_i_o_n__P_r_i_m_i_t_i_v_e_s

 Primitive services for files and directories are:

     - Read a portion of the file.

     - Write to a portion of the file.

     - Open access to a file.

     - Create a new file.

     - Close access to a file.

     - Delete a file.

     - Copy a file.

     - Merge two or more files.

     - Append one file to another.

     - Split one file into two or more files.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 60                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Support read and write locks at both the record and file levels.

 These services may be very complex.  For example, the access to read or
 write may be direct (by record number), sequential (one record at a
 time), or indexed (by a key).  The services must also support a variety
 of file structures, including linked, segmented, contiguous, serial, and
 directory.

 _F_i_l_e__S_u_p_p_o_r_t__S_e_r_v_i_c_e_s

 Additional services support the physical devices on which the files and
 directory reside.  These services include the dismounting/mounting of
 medium, the formatting of medium, and the partitioning of media.

 _R_e_a_l_t_i_m_e__F_i_l_e_s

 Realtime systems often need special files to ensure fast, bounded, and
 consistent performance in time critical situations.  The need for a
 bounded response time for a given I/O function drives the design of these
 files and services.  One service preallocates the complete disk space
 needed for a file at creation time, while another guarantees that records
 within files are aligned in an optimal way (such as along word
 boundaries).  Services support the access of records within the file in
 ways that make response time constant or bounded, including by direct
 access.

 4.2.4.1.7  Event, Error, and Exception Management Services

 These services provide a common facility for the generation and
 communication of asynchronous events among the system and application
 programs.  A major use of the event services is to report error
 conditions, but they are also used by device drivers and the platform to
 provide an indication of some condition to the application programs.
 These services are:

     - Event and error receipt.

     - Event and error distribution.

     - Event and error management, including user-selectable error
       processing alternatives (filtering, retry, ignore, accumulate
       occurrences).

     - Event logging.

     - Enable/disable and mask/unmask interrupts.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    61






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.2.4.1.8  Time Services

 Timers may be a static or dynamic resource on the system, necessitating a
 variety of allocation and management strategies.  These services are used
 by applications to perform a variety of services based on absolute and
 relative time.  These services are:

     - Create a timer.

     - Delete a timer.

     - Initiate the measurement of an arbitrary specified time duration.

     - Receive an indication when the specified duration has elapsed.

     - Read the current value of a timer.

     - Initialize a timer with a value and count direction (i.e.,
       increment or decrement).

     - Trigger a timer to begin incrementing or decrementing.

     - Associate with a timer some action to be taken when the specified
       duration has elapsed.

 4.2.4.1.9  Memory Management Services

 These services are used by application processes and tasks to request
 additional memory and return it to the processor for reuse.  They cover
 the services required to fulfill the needs of both virtual and fixed
 memory.  Specifically, there is a service for locking pages in real
 memory to support the needs of virtual memory systems.

 4.2.4.1.10  Logical Naming Services

 These services allow the usage of system resources through logical names
 rather than the actual hardware device naming conventions.  Furthermore,
 they allow the resources of other processor nodes to be accessed via a
 logical name so that no knowledge of the resource's location is needed
 and the resource's location may change over time.  Logical names are also
 used by security services to hide resources from unauthorized processes
 by only letting authorized processes know the logical name that is needed
 to use the physical resource.

 The logical name to physical name relationship can be one to many, many
 to one, or many to many.  Many times, one physical resource may have
 multiple logical names as well as one logical name representing a
 ``bank'' of available physical resources.  These services must provide
 the proper resolution of names, logical and physical, in all of these


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 62                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 cases.

 4.2.4.1.11  System Initialization, Reinitialization, and Shutdown
             Services

 System initialization consists of services for a complete restarting of
 the software, starting up the attached hardware subsystems devices, doing
 subsystem and system self tests, and completely initializing the
 database.

 System reinitialization consists of services for restarting the software
 while using the existing database information.  The software may have to
 be reloaded and the database may have been reestablished by a system
 recovery.  Attached hardware subsystems may also need to be
 reinitialized.

 Reinitialization also includes a function to restart applications
 redistributed to other processors after a processor module failure.
 Within a processor, there is a service to initialize applications in a
 system with the existing software, but with the database reinitialized.
 Also within a processor, there is a service to restart the applications
 in a system with the existing software and database retained.

 Shutdown services are those required to perform planned orderly shutdown
 at the local and remote levels for each and all processor(s) throughout a
 system.  These services support both crisis and non-crisis situations
 that call for system shutdown.  They make sure that the persistent store
 is in a consistent state, see to the clean termination of all processes,
 programs, devices, etc., and take care of user notification.  They also
 provide for the running of system diagnostics.

 4.2.4.2  External Environment Interface Services

 Data Interchange External Environment Interface Services are required by
 the System Services.  Of particular interest are the formats, locations,
 and procedures for using system administration files, such as password
 files, system startup files, and configuration files.

 4.2.4.3  Interapplication Software Entity Services

 This could include support for generalized network/multisession services,
 such as message handling between system components, global object
 definition specification, and intermediate language definition.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    63






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.2.4.4  Resource Management Services

 These services provide general management functions across the entire
 platform.  They consist primarily of system administration-oriented
 functions (i.e., management of system interfaces within the scope of the
 administrator, such as setting up defaults and limits.)

 4.2.4.4.1  System Operator Services

 The system operator needs to access and control the system services in
 order to allow the platform to perform properly.  If a system has an
 operator, the major functions that need to be supported are system
 control, reconfiguration, and status reporting.  Currently, these
 services are usually made available to an operator through a command
 language interpreter, which is an application program that accesses these
 system services.

 Note that the Windowing Services provide the building blocks (menu
 utilities, command parsers, etc.) for building the user interface while
 the System Operator Services make available operating system status and
 control functions to appropriate application programs with the proper
 security level.

 These services support general conventions and specifications for
 interaction between system components.

 4.2.4.4.2  System Administration

 These services and procedures are those required to assure management and
 allocation of system services to system users, both local and remote.
 They consist primarily of those services required to establish authorized
 users of the system, with associated allocation of processor resources,
 including memory, processor time, priority, and mass storage space.
 These services are both static (as in the establishment of a new user
 identification) and dynamic (as in login/logout).


 4.2.5  Standards, Specifications, and Gaps













              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 64                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


                  Table 4-2  -  System Services Standards
 __________________________________________________________________________________________________________________________________________________
               Service             Type   Specification    Subclause        e
     ________________________________________________________________       e

     Process Management             S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Task Management                S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Environment Services           S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Node Internal Comm/Synch       S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Generalized I/O                S     ISO/IEC 9945-1   4.2.5.1     e    ee
                                    G     OSF AES - OSC    4.2.5.3     e    ee
                                    G     SVID             4.2.5.3     e    ee

     File Oriented Services         S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Event, Error, and Exception    S     ISO/IEC 9945-1   4.2.5.1     e    ee
                                    G     OSF AES - OSC    4.2.5.3     e    ee
                                    G     SVID             4.2.5.3     e    ee

     Time Services                  S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Memory Management              S     ISO/IEC 9945-1   4.2.5.1     e    ee

     Logical Naming                 S     ISO/IEC 9945-1   4.2.5.1     e    ee

     System Init/Reinit/Shutdown    S     ISO/IEC 9945-1   4.2.5.1     e    ee
                                    G     OSF AES - OSC    4.2.5.3     e    ee
                                    G     SVID             4.2.5.3     e    ee
 __________________________________________________________________________________________________________________________________________________


 4.2.5.1  Current Standards

                                                                            e

 _P_o_r_t_a_b_l_e__O_p_e_r_a_t_i_n_g__S_y_s_t_e_m__I_n_t_e_r_f_a_c_e__(_P_O_S_I_X_)__P_a_r_t__1

 ISO/IEC 9945-1 (IEEE Std 1003.1) is the first in a set of planned
 international POSIX standards.  It defines services and characteristics
 that need to be in the platform for portable applications, as do some of
 the other planned standards.  Another type of POSIX-related standard is
 bindings for those services to specific languages.  The third type deals
 with concepts that cross between various groupings of services, such as
 security and distributed processing.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    65






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

                                                                            e
 The purpose of the ISO/IEC 9945-1 standard is to define a standard
 operating system interface based on the UNIX Operating System
 documentation to support application portability at the source level.
 The document is intended for systems implementors and applications
 software developers.

 In addition to ISO/IEC 9945-1, ISO is planning to publish another          e
 standard (as yet unnumbered) on test methods for verification of POSIX     e
 standards, which will be identical to IEEE Std 1003.3-1991.                e

                                                                            e
 Table 4-3 outlines the contents of POSIX.1 {2}.  This document is          e
 identical in its ISO/IEC form (ISO/IEC 9945-1) and the US national
 standard form (IEEE Std 1003.1).  Revisions are currently in progress to
 deal with:

     - A language-independent services specification

     - A unified data interchange format

     - Service interfaces for control of character cell terminals

     - Miscellaneous functions identified in comments on the current
       standard.

                                                                            e
 The ISO/IEC 9945-1 standard draws heavily upon major implementations of
 the UNIX Operating System, including System V and the Berkeley versions.
 Where a specific behavior was clearly needed (e.g., signals), only a
 single behavior was permitted.  However, there are points where functions
 were considered optional and others where two different behaviors were
 considered acceptable.  However, in many cases, a solid technical
 argument favoring one approach over the other was not established.  In
 this case, two behaviors (usually System V and BSD) are defined as being
 permitted.  This is of benefit in writing portable applications, since
 those that can tolerate both behaviors will run on a wider range of
 systems.  It is also a slight disadvantage in writing such applications,
 since it can mean handling a wider range of implementations.

 NOTE:  FIPS 151-1 is a profile of the base standard POSIX.1 {2}.           e

                                                                            e








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 66                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


              Table 4-3  -  Functionality of POSIX.1 Standard
 __________________________________________________________________________________________________________________________________________________

       File system organization, and file naming conventions

       System configuration and file system configuration
       characteristics

       Error messages and reporting mechanism (_e_r_r_n_o)

       Application environment information (_e_n_v_i_r_o_n)

       Process creation, management, and termination:  _e_x_e_c(),
       _f_o_r_k(), _w_a_i_t()

       Process environment: user ID, process ID, Group ID

       Exception conditions and handling (signals)

       Timer operations

       File and Directory operations:  FIFO files, pipes, status,
       open/close, read/write

       File protection mechanisms

       Record and file locking mechanism

       Device specific functions: Terminal controls:  Processing
       modes: echo, baud rate, modem termination

       C language specific routines:  _s_e_t_l_o_c_a_l_e(), nonlocal jumps

       User and Group database information (excluding password
       information)

       Data interchange formats (USTAR and CPIO)

       Also included is a rationale appendix that provides insight
       on the selection of various functions and features, including
       some guidance to developers to understand what types of
       variations may exist and how that can impact portability.

 __________________________________________________________________________________________________________________________________________________


 4.2.5.2  Emerging Standards



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    67






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

                                                                            e

 _I_E_E_E__P_1_0_0_3_._4                                                               e

 The IEEE P1003.4 Group is defining realtime extensions to ISO/IEC 9945-1.
 Draft 9 of the realtime POSIX extensions proposes standardized interfaces
 to the following functions:

     - Response to asynchronous events

     - Priority interrupts and scheduling

     - Preemptive scheduling

     - Memory locking

     - High-performance file system (contiguous or other)

     - Realtime timers (with nanosecond resolution times)

     - Shared memory

     - Semaphores

     - Interprocess communications (message passing)

     - Asynchronous event notification

     - Synchronous input and output.

 The P1003.4 group is also specifying an interface to threads (P1003.4a).

 4.2.5.3  Gaps in Available Standards

 While ISO/IEC 9945-1 and P1003.4 both represent very important work, they
 do not yet address all of the services indicated in 4.2.4.  Areas of
 particular shortfall include Event, Error, and Exception Management
 Services, some Generalized I/O Services (particularly concerning services
 for device drivers), and System Initialization, Reinitialization, and
 Shutdown Services.  In addition, Security (see 5.2) and Reliability,
 Adaptability, and Maintainability services are not reflected in these two  e
 base standards, and some capabilities are explicitly considered to be
 implementation defined.  For some of the services discussed here,
 adequate consideration is not given to the implications of multiprocessor
 and distributed implementations of the services and interface provided.
 Finally, since these are intended to be base standards (or, in the case
 of P1003.4, an extension to a base standard), profiles are needed in
 order to select appropriate features and provide appropriate combinations
 with other related capabilities.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 68                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.2.5.3.1  Public Specifications                                           e

 The following are public specifications that define interfaces to
 services for which no formal standards are currently available.

 _O_S_F_/_1

 The Open Software Foundation (OSF) ``Application Environment
 Specification (AES)--Operating System Component'' (OSC).

 Service Gaps Addressed:

     - Generalized I/O

     - Event, Error, and Exception

     - System Init/Reinit/Shutdown

 _S_V_I_D

 The AT&T System V Interface Definition (SVID), Issue 3.

 Service Gaps Addressed:

     - Generalized I/O

     - Event, Error, and Exception

     - System Init/Reinit/Shutdown

 _X_P_G_3                                                                       e

 X/Open's XPG3 specifications.                                              e

 Service Gaps Addressed:                                                    e

     - Generalized I/O                                                      e

     - Event, Error, and Exception                                          e

     - System Init/Reinit/Shutdown                                          e

 4.2.5.3.2  Unsatisfied Service Requirements

 There are two significant areas of the services described above for which
 no standards currently exist.  One is the considerations implied by the
 use of multiprocessors to implement some or all of the services described
 herein.  The other area is that of interfaces to logical device drivers.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    69






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.2.6  OSE Cross-Category Services

 4.2.6.1  Capability and Security Services

 These services support the ability of the system to control usage such
 that system integrity is protected from inadvertent or malicious misuse.
 These protection services provide a mechanism for the enforcement of the
 policies governing resource usage.  Note that many of the security
 services are implicit services; i.e., they are provided without an
 explicit request to the operating system.  There are two distinct classes
 of system access with which operating system services must be concerned:
 physical access and logical access.

 Security services at the physical level are used to protect against
 security compromise, given unauthorized personnel may have physical
 access to system hardware.  Typically, the physical access is to a
 terminal and/or terminal/display cables; however, physical access may
 also include network cables, central processing units, disk drives, or
 tape drives.  Prevention of physical access by unauthorized personnel may
 require different operating system services under different
 circumstances.

 Logical access is the ability to interact with the operating system via a
 terminal/display.  Security services at the logical level can be
 implemented through passwords and watchdog timers.

 Capability services attach operation lists that limit a process's ability
 to act on resource objects.  This is to ensure the resources are not
 misused.  Access to resources can be protected by services using
 capability lists as well as access lists, lock/key mechanisms, global
 tables, or through dynamic protection structure services.

 _P_r_e_v_e_n_t_i_o_n__o_f__U_n_a_u_t_h_o_r_i_z_e_d__A_c_c_e_s_s

 The system may need to be guarded from attempted access by unauthorized
 personnel.  The point of access to the operating system that is typically
 of concern is through the API.  Given the mode of operation (system high,
 multilevel, open) at which the system is operating, these services differ
 and have differing implications on other system services (such as
 reliability and naming) and system performance.

 _P_r_e_v_e_n_t_i_o_n__o_f__D_a_t_a__C_o_m_p_r_o_m_i_s_e

 These services prevent access of data by users not authorized to the
 data.  These services may be implemented using access lists on files (and
 directories) and/or encryption of data or in other ways.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 70                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _P_r_e_v_e_n_t_i_o_n__o_f__S_e_r_v_i_c_e__D_e_n_i_a_l

 These services ensure that a service request will be met by the operating
 system in a reasonable time if the requester is authorized to use the
 service.  These services ensure that a bandit user or process cannot
 cause system malfunction by monopolizing system services or resources.

 _S_e_c_u_r_i_t_y__A_d_m_i_n_i_s_t_r_a_t_i_o_n

 This category involves services to allow the management of the security
 system, including the administration of permissions to personnel, data,
 and services as well as capability lists.  In addition, it permits the
 administration access mechanisms (most often passwords and capability
 lists) and services that allow the system to switch modes of operation.
 The services will likely be accessed by the target system operator with
 security responsibilities through the target system operator services.

                                                                            e


 4.2.7  Related Standards

 The following emerging standards are related to the services covered in
 this clause, in as much as they address at some level services either
 explicitly listed in or implied by the services found in 4.2.4:

    P1003.6     Security Interface for POSIX.

    P1003.12    Protocol Independent Interfaces (for networks).

    P1238       OSI Application Program Interfaces (initial effort is to
                provide at least sufficient facilities for the support of
                FTAM API specifications).

                                                                            e
















              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.2 System Services                                                    71






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS




















































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 72                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.3  Network Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _C_h_a_r_l_e_s _S_e_v_e_r_a_n_c_e


 4.3.1  Overview and Rationale

 This clause describes the network services component of the application
 platform.  It also describes the services provided to application
 programs and users, and it describes current and emerging standards that
 are standardizing these services.

 Applications gain direct access to network services via the POSIX API.
 The network is just another system resource (albeit an important one)
 allocated among the competing processes.


 4.3.2  Scope

 Network services cover the areas of file transfer, namespace and           e
 directory services, electronic mail services, services in support of       e
 distributed environments such as remote procedure call, distributed time
 management, transparent file access, and data representation services.
 The application programs using these services should be able to access
 them via a high-level, context-insensitive or low-level, context-
 dependent interface.

 In the open systems and distributed system environments, interoperability
 is of equal or greater importance than portability.  The network
 protocols defined for both Open Systems Interconnect (OSI) and Internet
 Protocol Suite (IPS) for TCP/IP should provide the basis for the open
 networking interfaces; however, these interfaces should not preclude the
 use of some subsequent networking protocol in the future.  The interfaces  e
 provided by the network services must be network protocol independent and  e
 provide for this level of interoperability.                                e

 It is important for an open system to interoperate with more systems than
 just other open systems.  Many open systems users will have requirements
 to interoperate with non-OSI networks for the near future.                 e


 4.3.3  Reference Model

 This subclause identifies the entities and interfaces specific to the
 construction of an POSIX Network Environment.  This environment is
 consistent with and extends the environment of Section 3.

 As illustrated in Figure 4-3, the components of a network architecture
 that require standardization are divided into two groups called external


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   73






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________




















 _________________________________________________________________________
              Figure 4-3  -  POSIX Networking Reference Model


 environment interfaces (EEI) and application program interfaces (API).

 There may be some correspondence between services offered to the
 application across the API and the interfaces available at the EEI.  It
 is quite possible for an API service to have no corresponding effect at
 the EEI.  A good example of this is an interapplication communication
 service provided by the Network API between two applications on the same
 application platform.  There may also be services available at the EEI
 provided by the Application Platform that are not available at the API
 such as remote login services.

 4.3.3.1  Network Application Program Interface (API) Services

 The API is concerned with the interfaces and associated standards that
 apply to the interface between the application and the application
 platform.

 The services available at the API are:

     - Directory Services

     - Application to Platform Services




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 74                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Application to Application Communication Services

     - Data Representation Services Services

     - Distributed System Services

     - Network Management and Security Services

 Directory Services are those services associated with identifying and
 naming network elements.

 Application to Platform Services provide an application with a very high
 level interface to networking capabilities.  This interface provides
 applications with capabilities such as ``mail this file to this address''
 or ``transfer user xxx file from host yyy to the local host.''  These
 services do not require the application to be aware of any of the low
 level network details.

 Application to Application Services are the services provided by the
 Application Platform that allow an application to communicate with
 another application to exchange information.  These interfaces support
 applications that range from having extremely simple networking
 requirements to the most complicated applications that must make full use
 of every possible network capability.

 Data Representation Services provide the application with network
 oriented data representation services to insure the application can
 interchange information with other entities in the proper format.

 Distributed system services provide the application with the ability to
 make use of multiple physical computer systems resources.

 Network management and security services allow the application to control
 and configure the network resources.

 4.3.3.2  External Environment Interface Elements

 4.3.3.2.1  User Interface EEI Elements

 The User interface EEI elements include the commands that users can use
 to perform network functions such as:

     - File transfer

     - Electronic mail

     - Remote printing




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   75






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 These commands are considered to be beyond the scope of this clause and
 will be covered in 4.10.

 The User interface EEI elements that will be covered in this section are
 the commands that are used to perform network management and security
 functions.

 4.3.3.2.2  Communication EEI Elements

 The primary focus of the network EEI is the network protocols and
 supporting formats for network communication.

 The entities in the external environment may be other application
 platforms or user interface equipment connected to the network using the
 open networking protocols.  The standards at the EEI will be in several
 areas including:

     - Physical connections

     - Network protocols and formats

     - Distributed systems services

 The standards at the EEI will impact system interoperability but also may
 have an effect on application portability because certain applications
 may require particular types of network access to operate.

 4.3.3.3  Implementation Aspects

 The POSIX OSE Network reference model focuses on the requirements of
 application portability and system interoperability.  As such, the model
 does not represent how systems are actually put together.

 In the network area, there is much effort dedicated to the design of
 network standards to allow network components to be re-usable.  This
 subclause shows how some of these network standards are related within
 the POSIX Network Reference Model.

 Other network models are also related to the POSIX OSE Network Reference
 models.  None of these other models are in conflict with the POSIX OSE
 Network Reference model.  These models show much more detail in the area
 of how different standards work together.









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 76                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.3.3.3.1  Relationship Between the OSI Reference Model and the POSIX OSE
            Network Reference Model

 _________________________________________________________________________



















 _________________________________________________________________________
                    Figure 4-4  -  OSI Reference Model


 Figure 4-4 shows the OSI reference model for networking as standardized    e
 by ISO.                                                                    e

 There are many aspects of network architecture that are specified by the   e
 OSI reference model:                                                       e

     - The number of layers in the model and the roles for each layer.

     - An indication of which layers are logically end to end and which
       layers are simply to the next physical network node.

     - The services between the layers and the protocols between the peers  e
       within the same layer.  This has an impact on the actual format of
       the information transferred between nodes at the physical layer.

 In addition, this model specifies how networks of computer systems can be
 assembled using the routing capabilities of intermediate nodes.

 The POSIX OSE Network Reference Model has a much more limited scope than
 the OSI reference model.  The POSIX OSE reference model only looks at two  e
 interfaces to an application platform:  the interface between application
 software and the application platform (API) and the interface between the


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   77






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 application Platform and the External Environment (EEI).  At both the API
 and EEI, the POSIX OSE network model describes the services that are
 provided to the application or external environment at the interface.

 Figure 4-5 shows an example of how an application platform made up of a    e
 single computer system would provide services at the API and EEI.  It is   e
 important to note that the POSIX OSE application platform actually may be  e
 made up of multiple physical computer systems, as shown in Figure 3-5.     e
 In Figure 3-5, each computer system making up the distributed system       e
 would be running a complete OSI stack for networking.                      e

 Because the OSI portions of the Application Platform External Environment
 Interface depend on the format, protocol, and services of what is
 produced at the physical level of the OSI reference model, the EEI
 technically depends on all seven layers the OSI model plus the services
 added on top of the application layer such as platform provided services
 or network management services.

                                                                            e

 Figure 4-6 shows an API interface to only layer seven of the OSI Network
 interface, which is intended to be the primary API for accessing network
 services.  It is possible to define APIs that interact directly with any
 of the seven layers.  There are a number of pragmatic reasons to provide
 APIs that access layers below layer 7.  The cost of using one of these
 lower layer APIs is that the applications may sacrifice portability
 and/or interoperability.

 It is important to note that while these APIs are represented as a part
 of a layered network architecture, from the point of view of the
 application interacting with the application platform, this layering is
 not critical to the use of the services.  From the application
 perspective, there are simply three different types of network services,
 each with a different set of capabilities and requirements.  Whether or
 not there is any actual layering or code common to the three services is
 implementation dependent.

 4.3.3.3.2  POSIX Network Standards Efforts

 The current POSIX approach to networking focuses on producing Application
 Program Interface (API) specifications.  Most of the network connectivity
 specifications at the External Environment Interface are well covered on
 other standardization areas such as ISO (OSI networking) and the MIL-STD   e
 process (TCP/IP).                                                          e

 One important aspect of the POSIX networking approach is that it is not
 focusing solely on producing standard APIs for OSI Network services.  The
 POSIX Simple Network Interface (P1003.12 SNI) is explicitly designed so
 to be implemented transparently on a wide variety of networks.  At the


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 78                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________





































 _________________________________________________________________________
 Figure 4-5  -  Relationship of OSI and POSIX OSE Network Reference Models


 current time the possible list includes:

     - OSI Application Layer

     - OSI Transport Layer




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   79






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________

























 _________________________________________________________________________
      Figure 4-6  -  Multiple POSIX OSE APIs to Different OSI Layers


     - Internet Protocol Suite (IPS)                                        e

     - Other networks, including proprietary networks

 The current POSIX API standardization efforts include:

    P1003.12    Simple Network API

    P1003.12    Detailed Network API

    P1003.17    Directory Services API

    P1224       X.400 Electronic Mail Services API                          e

    P1224.1     OSI Object Management API                                   e

    P1238.0     OSI Application Layer API (ASCE)




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 80                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

    P1238.1     OSI Application Layer API (FTAM)

 _________________________________________________________________________































 _________________________________________________________________________
                Figure 4-7  -  POSIX Network Services Model                 e


 Figure 4-7 shows how the basic network services can be related.  The
 Simple Network Services API is designed so that a Simple Network Services
 Implementation can be done using the services available using the
 Detailed Network Interface API.  An application can use the Detailed
 Network Interface to access multiple network transports but there may be
 differences between networks visible at the API.  Applications that need
 to be portable across different types of network transports should be
 written using the Simple Networking Interface.

 It is important to note that while the SNI API and DNI API standards have
 been designed so that the SNI Services can make use of the DNI API to


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   81






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 access transport services, it is not a requirement that every
 implementation of SNI Services be written using the DNI API to access
 transport services.  From the point of view of the application program,
 it is only important that the application platform provide an API for
 both the SNI and DNI services.  This interface between the SNI Services
 and the Transport Services is an example of a Systems Internal Interface,  e
 as described in 3.6.

 Another example of a System Internal Interface that is the subject of      e
 discussion in the POSIX Network area is the interface between the OSI
 Network Services and the transport services.  This may or may not be
 required to be the DNI API.  This is an example of an interface that
 should have no impact on user application portability but may have great
 impact on the ability to procure the different types of network services
 from different vendors.

 The area of Directory Services (P1003.17) is also specified so to be able
 to make use of different types of Directory Services including:

     - X.500 Directory Services

     - TCP/IP Directory Services

     - IEEE P1003.7 System Administration and Management Services

 Figure 4-8 shows how the Directory Services are related to the other
 network services.  All of the APIs and SIIs from the previous figure have
 been eliminated to reduce the number of interfaces shown on the figure.


 4.3.4  Service Requirements

 The service requirements for the network component of an open system are
 very wide ranging.  Many of the other components of the application
 platform make implicit or explicit use of network services.

 Much standardization effort has gone into the aspects of networking that
 are available at the external environment interface.  Effective
 networking standards at the external interface are fundamental to
 providing system interoperability.

 The service requirements for both the API and EEI are described in this
 section.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 82                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________































 _________________________________________________________________________
              Figure 4-8  -  Directory Services Architecture


 4.3.4.1  Application Program Interface Services

 4.3.4.1.1  Directory Services

 Directory services allow an application to find the names and addresses
 of objects and services available to the application.  These services
 include the ability to:

     - Look up the name to be used to access a particular service

     - Look up the address of a named object




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   83






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.3.4.1.2  Application to System Services

 These are the services requested by the application that are performed by
 the Application Platform on behalf of the application without the
 application actually communicating directly with another application.
 Many of these services may actually connect to some remote application
 but the details of the connection are left up to the application
 platform.

 These services will be provided by a relatively simple high level API.
 These services include:

     (1)  File transfer

     (2)  Remote execution of commands

     (3)  Electronic mail                                                   e

     (4)  Remote login

     (5)  Remote printer access

     (6)  Network status

     - The ability to access remote or local systems using remote
       procedure calls (RPC).  When this type of access is provided,
       nearly all of the details of the network connection and interaction
       are masked from the application.

 4.3.4.1.3  Application to Application Service

 There are three areas of application to application service requirements:

     - RPC Services

     - Simple Network Services

     - Detailed Network Services

 The RPC services allow an application to register with the network
 application platform as the provider for a particular RPC Service.  Once
 the service has been properly registered, other applications can
 transparently request services using a subroutine call.  The details of
 communicating the service request to the application that is registered
 to provide the service and the return of the response to the requesting
 application are handled transparently by the Application Platform.

 Applications making use of RPC services may not even be aware that the
 service are being provided via an RPC mechanism.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 84                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 The Simple Network Services are application to application services
 provided using a simple set of interface routines.  These will allow a
 wide variety of networking applications to be written that do not need to
 exercise control their network access at a very complex level of detail.

 In addition, these services should be provided over a wide variety of
 network transport mechanisms.  Applications written exclusively using the
 simple services should be portable across a wide variety of networking
 environments.

 Applications written using the simple network services may not be able to
 make use of unique advantages of a particular physical networking scheme.
 To make use of these network-specific features the Detailed Network
 Services must be used.

 The service requirements for the simple network services are intended to
 be the minimum requirements to write a large subset of network
 applications.

 The Simple Network Services sacrifice the capability to control every
 detail of the network services in the interest of portability across
 networking environments and applications simplicity.

 The Detailed Network Services API allows the application to control over
 much more detail of the network services.  In addition, using the
 Detailed Network Services an application may be able to make use of
 unique networking capabilities available in particular networking
 environments.

 4.3.4.1.3.1  _R_P_C__S_e_r_v_i_c_e_s

 These service requirements include the ability:

     - To register as an RPC service provider

     - To wait for incoming requests

     - For an application using RPC services to control parameters such as
       timeout

 4.3.4.1.3.2  _S_i_m_p_l_e__N_e_t_w_o_r_k__S_e_r_v_i_c_e_s

 The services provided at the simple network interface are:

     (1)  Name resolution

     (2)  Connection oriented services




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   85






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

           - The ability to indicate willingness to accept incoming
             connections

           - Establishing and destroying connections

           - Data transfer over connections

              +o Read

              +o Read with timeout

              +o Write

              +o Write with timeout

           - Simple error handling

              +o Connection dropped notification

              +o Connection read failure

              +o Connection write failure

           - The ability to close a connection

              +o Unconditionally

              +o Only after all data has been received

     (3)  Connectionless services

           - The ability to indicate willingness to accept incoming
             requests

           - The ability to send requests

              +o With acknowledgment

              +o Without acknowledgment

              +o Specified timeout

           - The ability to receive requests

              +o Wait unconditionally

              +o Wait with timeout




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 86                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

           - The ability to query as to whether any requests are available

           - Simple event notification

              +o Lost request

              +o Request acknowledgment

           - Simple error handling

              +o General network failure

     (4)  Support for server applications

           - The ability to register as the provider for a service

     (5)  Simple status inquiry

           - General network availability

 4.3.4.1.3.3  _D_e_t_a_i_l_e_d__N_e_t_w_o_r_k__S_e_r_v_i_c_e__R_e_q_u_i_r_e_m_e_n_t_s

 The services provided at the Detailed Networking Interface include all of
 the service requirements in the Simple Network Service Requirements plus
 the following abilities:

     (1)  Query the network services to get detailed information about
          network configuration and status

     (2)  Specify performance metrics

     (3)  Control routing

     (4)  Select between different network protocols

     (5)  Negotiate capabilities

           - Required capabilities

           - Optional capabilities

           - Determine the results of the negotiation

     (6)  Information with different priorities

     (7)  Request and process extended event notification

     (8)  Request and process extended error recovery including allowing
          the application to completely control error recovery.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   87






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     (9)  Make full use of network resources for performance critical
          applications

 This should provide the application with the ability to completely
 control connection oriented services and connectionless services.

 4.3.4.1.4  Data Representation Services

     - The ability to access all of the data representation and format
       conversion services to allow an application to communicate with a
       wide variety of computer systems.

 4.3.4.1.5  Distributed System Services

 The services provided in this area include the ability to:

     - Identify available resources in a distributed system

     - Dynamically make use of the resources in a distributed system.

     - Access files regardless of the physical location of the files.

     - Have reliable time services across all of the resources of the
       distributed system.

 4.3.4.1.6  Network Management Services

 The services provided at the Network Management API are abilities to:

     (1)  Manage

           - Network objects

           - Network relationships

           - Network security

     (2)  Monitor and report on

           - Network events

           - Network service alarms

           - Network security alarms

     (3)  Log

           - Network events



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 88                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

           - Network availability

           - Network load

           - Network performance

     (4)  Test network performance and reliability

 4.3.4.2  External Environment Interface Services

 At the external interface, there are several types of services that are
 provided.  These include:

     - Data transfer and connectivity

     - Routing and relay services

     - Services provided by the application platform directly to an
       incoming connection

     - Network management and security services provided to other networks
       and other nodes within a network

     - Network management user interface

 This clause does not address the user interface to the general network
 services such as file transfer or mail sending.  That is covered by the
 command interface clause, 4.10.  As stated above, this clause covers the
 network management user interface.

 In addition, there are a number of other areas of external interface
 requirements that are not covered in this guide.  They include:

     - Physical network interface connections

     - Electrical specifications for network connections

     - Specifications for physical network construction

                                                                            e

 4.3.4.2.1  Data Transfer and Connectivity

 Services required at the EEI in the area of data transfer and
 connectivity include the ability to:

     - Connect and interoperate with other standards-based systems using
       standards-based protocols including X.25 and OSI.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   89






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Connect and interoperate with systems using de facto networking      e
       standards such as TCP/IP and UUCP.                                   e

     - Connect and interoperate with personal computer and workstation
       networks.

     - Interoperate with industry leading networking interfaces.

 4.3.4.2.2  Routing and Relay Services

 Services required at the EEI in the area of routing and relay
 capabilities include the ability to:

     (1)  Relay information through a system between like networks.

     (2)  Gateway information through a system between unlike networks at
          a data transfer level.  Examples of this type of gateway
          include:

           - Local Area Network (LAN) to LAN

           - LAN to Wide Area Network (WAN)

           - WAN to Global Area Network (GAN)

           - Networks to point-to-point connections

           - Point-to-point connections to networks

     (3)  Convert information from one format to another when transferring
          between unlike computer systems or networks.  Information that
          may need to be converted includes:

           - Mail messages

           - File contents

           - Printer file contents

 The primary requirement for the routing and gateway services is to make
 any necessary relays and gateways transparent to the applications and
 systems using the network.  This requires complete gateways and relays.

 4.3.4.2.3  Services Provided by the Application Platform at the EEI

 These EEI services are those provided to incoming connections that are
 not directed to an end-user application or server.  These incoming
 connections are directed to standard services that can be provided by
 systems.  These services include:


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 90                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Remote logon and terminal emulation

     - Remote execution of commands

     - File transfer services

     - Remote authentication

     - Remote data access

     - Remote status information

     - Mail delivery services

     - Directory services

 To access these services each user does not need to provide an
 application on the remote host.  Simply by connecting to the service, the
 application platform will provide the service.


 4.3.5  Standards, Specifications, and Gaps

 4.3.5.1  Current Standards

 Table 4-4 lists standards that address the services outlined in this       e
 clause.  This table includes international standards, emerging standards   e
 coming from national and international bodies, and other current           e
 standards that meet gaps in the service requirements.  Public              e
 specifications are cited to fill gaps only when there are no existing or   e
 emerging standards to meet the service requirements.                       e

 _I_S_O__P_r_o_t_o_c_o_l__S_t_a_c_k__S_t_a_n_d_a_r_d_s                                               e

 Figure 4-9 describes how the ISO protocol standards cited in this guide    e
 fit together.                                                              e

 4.3.5.2  Emerging Standards

 _I_E_E_E__P_1_0_0_3_._1_2                                                              e

 This group is developing a standard that provides networking application   e
 program interfaces.  P1003.12 contains the specification for a Simple      e
 Network Interface (SNI) and a Detailed Network Interface (DNI).  The       e
 Simple Network Interface is designed to usable on a number of different    e
 transport services, ranging from ISO networks to completely proprietary    e
 networks, without requiring application changes.  To do this, the SNI has  e
 a very limited set of services with minimal parameters.  The Detailed      e
 Network Interface is also designed to be implementable across a wide       e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   91






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS


                    Table 4-4  -  Networking Standards
 __________________________________________________________________________________________________________________________________________________
          Service            Type                Specification                Subclause e
 _______________________________________________________________________________________e

 Directory Services           S     X.500                                     4.3.5.1   e ee
                              E     IEEE P1003.17 X.500 API                   4.3.5.2   e ee

 Message Handling             S     ISO 10021 X.400                           4.3.5.1   e ee
                              E     IEEE P1224 X.400 API                      4.3.5.2   e ee

 File Transfer                S     ISO 857, ISO 8613, ISO 10026, ISO 8650,   4.3.5.1   e ee
                                    ISO 8652, ISO 8653, ISO 9735, ISO 9594              e
                              E     IEEE P1238 FTAM API                       4.3.5.2   e ee

 Print Services               E     X3H3                                      4.3.5.2   e ee

 Application Services                                                                   e
       Connectionless         S     ISO 8649-2, ISO 8650-1                    4.3.5.1   e ee
       Connection Oriented    S     ISO 10040, ISO 10164, ISO 10165,          4.3.5.1   e ee
                                    ISO 9595, ISO 9596, ISO 9579                        e
                              E     IEEE P1238.1 ASCE API                     4.3.5.2   e ee

 Data Representation          S     ISO 8823 Presentation Protocol            4.3.5.1   e ee
                              S     ISO 9576, ISO 8824, ISO 8825 ASN.1        4.3.5.1   e ee

 Protocols                                                                              e
       Session                S     ISO 8327, ISO 9548                        4.3.5.1   e ee
       Transport              S     CCITT X.214, X.224 (TP0)                  4.3.5.1   e ee
                              S     ISO 8072, ISO 8602 (TP4)                  4.3.5.1   e ee
                              E     IEEE P1003.12 Transport API ??            4.3.5.2   e ee
       Network                S     CCITT X.25 PLP, ISO 8208                  4.3.5.1   e ee
                              S     ISO 8348 AD1, ISO 8473                    4.3.5.1   e ee
       Data Link              S     ISO 7776 HDLC/LAPB                        4.3.5.1   e ee
                              S     ISO 8802-2 Logical Link Control           4.3.5.1   e ee
       Physical               S     EIA RS-232                                4.3.5.1   e ee
                              G     MIL-STD-114A                              4.3.5.3   e ee
                              S     ISO 8802-3 (CSMA/CD)                      4.3.5.1   e ee
                                    ISO 8802-4 (Token Bus),                             e
                                    ISO 8802-5 (Token Ring)                             e
 _________________________________________________________________________









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 92                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


               Table 4-4 - Networking Standards (_c_o_n_c_l_u_d_e_d)
 _________________________________________________________________________  e
           Service             Type              Specification               Subclausee
 _____________________________________________________________________________________e

 Network Management             S     ISO 9596                               4.3.5.1  e       ee
                                S     ISO 9593                               4.3.5.1  e       ee
                                S     ISO/NMF                                4.3.5.1  e       ee

 Network Security               S     ISO 803.10                             4.3.5.1  e       ee
                                E     X3T4                                   4.3.5.2  e       ee
                                E     SIRS 233                               4.3.5.2  e       ee

 Distributed System Services    S     ISO DP                                 4.3.5.1  e       ee
                                E     IEEE P1003.8 TFA API                   4.3.5.2  e       ee

 Remote Procedure Call (RPC)    E     ECMA 127                               4.3.5.2  e       ee
                                E     ISO 10148                              4.3.5.2  e       ee
                                E     IEEE P1237 API                         4.3.5.2  e       ee

 Protocol-Independent                                                                 e
 Network Interface              E     IEEE P1003.12 SNI API                  4.3.5.2  e       ee

 Interoperable Networking                                                             e
       Directory Services       G     RFC-1034 Domain Naming                 4.3.5.3  e       ee
                                E     IEEE P1003.17 Directory Services API   4.3.5.2  e       ee
       File Transfer            G     MIL-STD-1780 (TCP/IP FTP)              4.3.5.3  e       ee
       Message Handling         G     MIL-STD-1781 (TCP/IP SMTP)             4.3.5.3  e       ee
       Virtual Terminal         G     MIL-STD-1782 (TCP/IP Telnet)           4.3.5.3  e       ee
       Protocols                G     MIL-STD-1777 (IP)                      4.3.5.3  e       ee
                                G     MIL-STD-1778 (TCP)                     4.3.5.3  e       ee
                                E     IEEE P1003.12 API                      4.3.5.2  e       ee

 Mainframe Networking           E     IEEE P1003.12 API                      4.3.5.2  e       ee
                                G     X/Open CPIC                            4.3.5.3  e       ee

 PC Networking                  G     X/Open PCI:SMB                         4.3.5.3  e       ee

 __________________________________________________________________________________________________________________________________________________











              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   93






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________








































 _________________________________________________________________________
               Figure 4-9  -  OSI Network Services Standards








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 94                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 variety of network protocols.  However, DNI allows applications to access  e
 the low-level details of each of the different network protocols.  As a    e
 result, programs written using DNI may be portable between environments    e
 that use the same underlying network protocols.                            e

 Applications can be written using a combination of the SNI and DNI         e
 interfaces.  The engineers designing the applications can make             e
 portability tradeoffs as the applications are developed.                   e

 _I_E_E_E__P_1_0_0_3_._1_7                                                              e

 This group is developing an API standard that will enable applications to  e
 access directory services.  Backwards compatibility with existing name     e
 resolution services, such as TCP/IP, is included in the design of the      e
 P1003.17 interface.  P1003.17 can also use the following directory         e
 services:                                                                  e

     - X.500                                                                e

     - TCP/IP                                                               e

     - IEEE P1003.17 System Management Name Space                           e

     - Others                                                               e

 _I_E_E_E__P_1_2_3_8                                                                 e

 This group is developing an API for connection-oriented Application Layer  e
 services.  It establishes a specification methodology and defines an API   e
 to:                                                                        e

     - OSI Association Control Service Element (ACSE) services and          e

     - common support functions for OSI connection-oriented protocol APIs.  e

 The specification is operating system and language neutral; POSIX and C-   e
 language bindings are provided.  Further, it is intended to be used as     e
 the basis for the connection management interface for the future           e
 Application Service Elements (ASE) such as the File Transfer, Access, and  e
 Management (FTAM) API.                                                     e

 _I_E_E_E__P_1_2_3_8_._1                                                               e

 This group is developing an API for interfacing with the FTAM application  e
 layer element.  It is standardizing an X.400 API and a companion OSI       e
 Object Management API, based on the X.400 API and an OSI Management API    e
 developed by the X.400 API Association and X/Open.  The X.400 API          e
 consists of two parts:  an X.400 application API and an X.400 gateway      e
 API.  These APIs were developed based on the 1988 CCITT X.400 series of    e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   95






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 recommendations.  The X.400 API and Object Management API are separate     e
 documents.                                                                 e

 The purpose of the X.400 API is to provide standard interfaces supporting  e
 the development of applications that are users of the message transfer     e
 system, and gateways that incorporate or use X.400 mail functionality;     e
 this includes gateways between X.400 mail networks and proprietary mail    e
 systems.                                                                   e

 The purpose of the companion OSI Object Management API is to provide a     e
 standard interface supporting the manipulation of complex arguments and    e
 parameters used by the X.400 and Directory Services APIs.  The scope of    e
 the OSI Object Management API is to define an ASN.1 Object Management API  e
 for use in conjunction with, but otherwise independent of, the X.400 and   e
 Directory Services APIs that are currently being standardized.             e

 4.3.5.3  Gaps in Available Standards                                       e

 This subclause describes the standards that are cited to satisfy           e
 identified service requirements that are not satisfied by any existing or  e
 emerging standard.                                                         e

 _I_n_t_e_r_o_p_e_r_a_b_l_e__N_e_t_w_o_r_k_i_n_g__S_t_a_n_d_a_r_d_s                                         e

 This set of protocol standards is the traditional TCP/IP suite of          e
 standards, which are currently widely available on many computer           e
 platforms and operating systems.                                           e

 This group of specifications includes:                                     e

    TCP/IP         MIL-STD-1777, MIL-STD-1778                               e

    TELNET         MIL-STD-1782                                             e

    FTP            MIL-STD-1780                                             e

    SMTP           MIL-STD-1781                                             e

 While these protocols are not expected to be standardized at any higher    e
 level than the MIL-STD level shown, it will be necessary for open systems  e
 to interoperate with these standards in a backwards-compatibility mode     e
 for some time.                                                             e

 _L_o_w__C_o_s_t__W_i_d_e__A_r_e_a__N_e_t_w_o_r_k_i_n_g                                              e

 The UUCP (UNIX-to-UNIX Copy Protocol) services and commands, for           e
 electronic mail and file copying, which are traditionally included in      e
 UNIX and UNIX-like systems are not addressed by any standards effort.      e
 Among other reasons, UUCP is not currently being addressed because of the  e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 96                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 inability of the POSIX groups to decide whether the UUCP services and      e
 commands should be standardized in the POSIX.2 Group (since UUCP is a      e
 traditional UNIX service with traditional command interfaces) or in the    e
 networking groups (since UUCP is an electronic mail and file copying       e
 facility that works on networks).                                          e


 4.3.6  OSE Cross-Category Services                                         e

 These EEI Services allow remote systems to be managed and monitored.       e
 Network management services include the ability to:                        e

     - Get network status information                                       e

     - Get network configuration information                                e

     - Test network functionality                                           e

     - Make network configuration changes                                   e

 The security services allow the system management to control access to     e
 system resources and system information.  Security services include:       e

     - Protect the system from intruders                                    e

     - Provide selective access to sensitive system resources               e

     - Manage the network security                                          e

 See also 5.3.                                                              e


 4.3.7  Related Standards                                                   e

 ISO 8587, Distributed Transaction Services; see 4.6.                       e
















              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.3 Network Services                                                   97






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS




















































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 98                               4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.4  Database Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _S_a_n_d_r_a _S_w_e_a_r_i_n_g_e_n


 4.4.1  Overview and Rationale

 This subclause describes an overview of an architectural framework for
 discussing database management.  It also describes the services provided
 to application programs and users, and it describes standards, current
 and emerging, that standardize those database services.

 Database management is an important component of the POSIX Open System
 Environment; in a large class of application programs, especially those
 used in business, database access through a database management system
 plays a key role.  For portability and interoperability, an application
 using a database must be isolated from the hardware and software
 retrieval methods as much as possible.  Otherwise the application must
 have the data manipulation capability coded in its own programs.  This
 might be done if performance is a key issue and the data is very unique.
 The cost is portability and interoperability.

                                                                            e


 4.4.2  Scope

 Included within the component of database management are various
 structured ``data models,'' including indexed files and network,
 relational, semantic, and object-oriented databases.  Specifically
 excluded from consideration are services for accessing data that is not
 part of a database.  This subclause discusses database management
 services from both the application program and user points of view.

 Database services provided to application programs by this component, for
 example, include the ability to create, alter, or drop tables, records,
 and fields and the ability to insert, select, and update data included in
 the structures above.

 Included within this component are also utility capabilities such as
 database administration services.

                                                                            e








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.4 Database Services                                                  99






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.4.3  Reference Model

 4.4.3.1  Reference Model

 In this subclause, the conventional view of Database Management is
 related to the POSIX reference model described earlier.

 The application programmer's view of the database model is introduced
 first.  Quite simply, an application program, through a _D_a_t_a_b_a_s_e _A_P_I,
 requests database services.  For convenience in the following discussion,
 the agent responsible for providing those services is called the _D_a_t_a_b_a_s_e
 _M_a_n_a_g_e_r.  The database manager is responsible for providing the
 application access to the _D_a_t_a_b_a_s_e.  See Figure 4-10.

 _________________________________________________________________________



















 _________________________________________________________________________
              Figure 4-10  -  The Traditional Database Model


 This figure also demonstrates the concept of a _D_a_t_a_b_a_s_e _U_t_i_l_i_t_y _P_r_o_g_r_a_m:
 one or more special application programs, usually provided by a database
 vendor, that perform utility services on the database.  Such utilities
 might reorganize the database, recover the database after a system
 failure, etc.

 The traditional database model can be incorporated into the POSIX
 reference model, as in Figure 4-11.  This depiction of the model shows
 that the database manager is really just part of the overall POSIX Open
 System Environment and is available to the application through the POSIX
 OSE API.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 100                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________






















 _________________________________________________________________________
              Figure 4-11  -  POSIX Database Reference Model


 The model depicted in Figure 4-11.  is sufficient to describe an
 application developer's view of the POSIX OSE API in general, and the
 database API specifically.  The four lines labeled ``Database API''
 represent the Database Applications Program Interface services, which are
 discussed in 4.4.4.1.

 4.4.3.2  Implementation Aspects

 Some real world considerations of the POSIX Reference Model were
 discussed in 3.6.  One of the real-world approaches described is
 ``layering.''  Note that in the marketplace, Database Managers are often
 independently purchasable components that are effectively implemented as
 layers.  Another consideration is Database Manager portability.  It is
 not a requirement that a a database manager sit on top of a POSIX OSE
 API, but there is very important value to the user in terms of
 portability if the database manager implementation does indeed sit on a
 POSIX API.  This means that the database manager itself is portable.  It
 should be noted that there will probably be implementations available of
 database managers that do not, in fact, sit on top of a POSIX API (or sit
 only partially on top of a POSIX API), that nonetheless provide the user
 the same database API.  Such an implementation, using both POSIX API
 services and non-POSIX API services was described as ``expansion'' (see


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.4 Database Services                                                 101






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 3.6.1).  Note that even though the model is drawn with only a single
 database manager, that does not imply that there may only be a single
 database manager available to an application.  In fact, the coexistence
 of several database managers on the same system is consistent with this
 model, as is the ability of a single application to access two or more
 different database managers.  The following extensions to the above model
 are specifically accommodated:

     - There may be more than one database API.  For example, there may be
       an ``SQL'' API and an ``ISAM'' API.

     - There may be more than one database manager implementation for each
       different API.  (For example, by two competing database vendors.)

     - Applications may access more than one database manager.

 This document has not described how a database manager is implemented in
 a POSIX Open System Environment, nor is it within the scope of this
 document to do so.  It should be noted, though, that this model is very
 general and does not constrain the implementor.  This model supports a
 number of varying real world implementation techniques, including:

     - Application and database manager linked into a single process.

     - Database manager consisting of more than one process.

     - Database manager consisting of a client part linked into the
       application process and a server part running as a process on the
       same or another system.


 4.4.4  Service Requirements

 The Database Manager described in the previous subclause provides
 services to the Application Program via the Database API, and the
 Database Utility Programs provide other services (e.g., to human users
 such as a ``Database Administrator'').  This subclause describes the
 service requirements of all service users of the system.  It is intended
 to be a complete list of service requirements rather than examples.
 Database Services are the specialized data services required to create,
 access, and manage databases located on a processor node.  Users of these  e
 services include end users and those charged with the ongoing management
 of the information processing and database infrastructure.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 102                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.4.4.1  Application Program Interface Services

 This subclause describes the major categories of database services
 available at the POSIX Application Program Interface (API).  These
 services include:

     - Data Definition and Manipulation Services

     - Data Access Services

     - Data Integrity Services

     - Miscellaneous Services

 The following paragraphs clarify that these services should be provided
 for a large class of objects, access methods, and types of database
 systems.

    Types of Data Objects
             Ability to perform the above operations on a variety of types
             of data objects, such as text, graphics, image, documents,
             and voice.

    Types of Access Methods
             Ability to perform the above operations using a variety of
             access methods, such as indexed sequential access, nonindexed
             sequential access, and direct access.

    Types of Database Management Systems
             Ability to perform the above operations on a variety of types
             of file and database management systems, and database
             management systems, such as relational, network, semantic,
             and object oriented databases, and heterogeneous combinations
             of these database management systems.

 4.4.4.1.1  Data Definition and Manipulation Services

 These services relate to the ability of application programs to define
 and manipulate data.  These services are:

     - Data definition -- ability to create, alter, or drop tables, views,
       records, fields, and/or data

     - Data Manipulation -- ability to insert, select, update, and delete
       tables, views, records, fields, and data






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.4 Database Services                                                 103






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.4.4.1.2  Data Access Services

 These services relate to the ability of application programs to
 interrogate databases.  These services are:

     - Data Query Facilities -- ability to specify search conditions,
       consisting of a combination of select lists, predicates, and
       comparison operators

     - Data Transparency -- ability to transparently access data
       regardless of the location of that data.

     - Remote Data Access -- ability to access and update remote data

 4.4.4.1.3  Data Integrity Services

 These services relate to the ability of database management systems to
 protect the databases from hardware and software malfunctions.

     - Locking -- ability to specify locking of data to some degree of
       granularity

     - Consistency -- ability to specify and execute check and referential
       constraints that help ensure data correctness

     - Transaction Control -- ability to specify commit and rollback
       commands and guarantee serializability for database transactions     e

     - Synchronous Writes (Durability?) -- ability to force the writing of
       data to nonvolatile storage

 4.4.4.1.4  Miscellaneous Database Services                                 e

 Miscellaneous database services include:                                   e

     - Privilege Administration -- ability to grant and revoke privileges
       for accessing and administering data

     - Exception Handling -- ability to have applications that are
       interrupted and notified of exception conditions, to receive
       control of the machine and take action in response to these
       exception conditions--even if the action is to ``continue''

     - Screen Definitions -- ability to create screen definitions, and
       define, display, and/or paint screens to communicate information     e
       about databases                                                      e

     - Reporting -- ability to create formatted reports.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 104                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Dynamic Facilities -- ability to temporarily turn control of a
       database to the end user for interactive access and manipulation of
       data, and then return control to the application.

     - Data Dictionary Services -- ability to get data about the data
       (i.e., metadata) stored in the database.  This allows users and
       applications to use the database contents in a much more flexible
       way.  These services allow a user to create, access, and manage
       this metadata much in the same way as other databases are
       maintained.

 4.4.4.2  External Environment Interface Services

 External Environment Interface services are required for distributed
 database management systems.  Also, to enable two or more databases to
 communicate with each other, a common interchange format is required.
 See 4.5.

 4.4.4.3  Database Resource Management Services

 These services are not visible to the application programmer at the
 Database API.  These services are usually provided by Database Utility
 Programs.  These services include:

     - Database Administration Services

     - Database Recovery Services

     - Distributed Database Management Services

     - Heterogeneous Environment Support Services

 4.4.4.3.1  Database Administration Services

 Database administration services refer to the ability for a designated     e
 data administrator to structure and configuration manage a database as a
 whole.  The administrator allocates resources and monitors utilization to
 assure that authorized users receive the proper services.  Archive
 functions, journaling, and logging services are available to the user and
 administrator on a selective basis.

 4.4.4.3.2  Database Recovery Services

 Database recovery services refer to the ability to decide that there has   e
 been a failure, allow recovery from failure, and permit a slave copy to
 become a master copy.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.4 Database Services                                                 105






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.4.4.3.3  Distributed Database Management Services

 Distributed database management services support the partitioning and      e
 partial replication of the databases.

 4.4.4.3.4  Heterogeneous Environment Support Services

 Heterogeneous environment support services permit local database systems   e
 to be of different types (e.g., inverted list, hierarchical, network,
 relational) by providing translators between the local database form and
 a general ``network language.''

 4.4.4.3.5  Flagger

 A flagger is software that alerts programmers about any code that does     e
 not conform to the standard in question, such as the Structured Query      e
 Language standard.                                                         e


 4.4.5  Standards, Specifications, and Gaps

 There are currently four database standards, either completed or under
 development.  These are the relational data language SQL, a network data
 language called NDL, the Information Resource Dictionary System (IRDS)
 for data dictionary work, and a Remote Data Access (RDA) protocol.
 Table 4-5 summarizes the service requirements provided by the various
 standards.

 4.4.5.1  Current Standards

 This subclause describes the current accepted standards that apply to
 this area.

 _S_Q_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e

    ISO 9075 (FIPS 127)                                                     e

    ANSI X3.168

                                                                            e

 ISO 9075 provides for many of the services described in 4.4.4, including   e
 Data Definition, Manipulation, and Integrity.  It provides for two levels
 of compliance:  the weaker Level 1 and the more capable Level 2.  While    e
 ISO 9075 deals with SQL independently of programming language, X3.168      e
 binds, or embeds, SQL within the programming languages COBOL, FORTRAN,
 Pascal, PL/1, C, and Ada.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 106                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


                     Table 4-5  -  Database Standards
 __________________________________________________________________________________________________________________________________________________
           Service             Type        Specification         Subclause
 _________________________________________________________________________
 Data Definition and            S     SQL:  ISO 9075             4.4.5.1    eeee
 Manipulation Services                      ANSI X3.168                     ee
 Data Access Services                                                       e
 Data Integrity Services                                                    e

 Data Definition and            S     NDL:  ISO 8907             4.4.5.1    eeee
 Manipulation Services                                                      e
 Data Access Services                                                       e
 Data Integrity Services                                                    e

 Miscellaneous Services         E     IRDS: ISO DP 10027 N2642   4.4.5.2    eeee
 (Data Security and                         (IRDS Framework),               ee
 Integrity, Exception                       ISO DP 8800 N2132               ee
 Handling, Screen                           (IRDS Interfaces),              ee
 Definitions, Reporting,                    ANSI X3.138                     ee
 Dynamic Facilities, Data                                                   e
 Dictionary Services)                                                       e

 Database Resource                                                          e
 Management Services                                                        e
 (Database Administration,                                                  e
 Recovery From Failure)                                                     e

 External Environment           E     RDA:  ISO/IEC DP 9759      4.4.5.1    eeee
 Interface Services                                                         e
 __________________________________________________________________________________________________________________________________________________


 Work is currently planned by ANSI and ISO to include ``generalized
 triggers,'' ``generalized assertions,'' ``recursive expressions,''
 ``escape from SQL,'' subtables, and support tools for object oriented and
 knowledge-based systems.

 _N_D_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e

    ISO 8907

    ANSI X3.133

 This standard, developed in 1981-1986 by the ANSI X3H2 Database
 Committee, specifies a data definition language (DDL) and data
 manipulation language (DML) for network model databases.  This work is an
 outgrowth of the 1978 CODASYL specifications.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.4 Database Services                                                 107






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 This standard provides for many of the services described in 4.4.4,
 including Data Definition, Manipulation, Access, and Integrity.  The
 above services apply only to network databases (i.e., not to relational
 or semantic databases.)

 No follow-on NDL activities are being conducted by ISO or ANSI.

 4.4.5.2  Emerging Standards

 This subclause describes the activities currently in progress to further
 standardize this area.

 _R_e_m_o_t_e__D_a_t_a__A_c_c_e_s_s__(_R_D_A_)__P_r_o_t_o_c_o_l

    ISO DP 9579-1              _G_e_n_e_r_i_c _R_e_m_o_t_e _D_a_t_a_b_a_s_e _A_c_c_e_s_s -- DP 2       e

    ISO DP 9579-2              _S_Q_L _S_p_e_c_i_a_l_i_z_a_t_i_o_n -- DP 1                   e

 This standard, developed by the ECMA Technical Committee on Database
 Standards, TC22, submitted to ISO in 1985, specifies a protocol that
 allows remote access and updating, via OSI communications protocols, of
 relational databases or of database systems that support SQL.

 This standard provides for the Data Transparency, Remote Data Access, and
 Support for Heterogeneous Environment requirements described in 4.4.
 This protocol is aimed at relational databases and other database types
 that provide access via relational interfaces such as SQL.

 Much work is planned on in this area by the ISO committee ISO
 TC97/SC21/WG3.  A specific area of current interest is a generic RDA that
 uses a nonspecific database language (i.e., not SQL.)

 _I_n_f_o_r_m_a_t_i_o_n__R_e_s_o_u_r_c_e__D_i_c_t_i_o_n_a_r_y__S_y_s_t_e_m__(_I_R_D_S_)

    ANSI X3.138                FIPS Pub 156, April 5, 1989

    ANSI X3H4/90-28 (draft, 4 Apr 90)
                               IRDS Export/Import File Format

    ISO DP 10027 N2642 (1988)  IRDS Framework

    ISO DP 8800 N2132 (1988)   IRDS Services Interfaces

 These standards are being developed by the ANSI X3H4 Database Group and
 the ISO/IEC /JTC 1/SC21 Working Group 3.  Both groups are addressing the
 general area of data dictionaries, but, as described below, the emphases
 of the activities differ.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 108                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 The ANSI group primarily addresses the user interface area; that is, how
 a human user can access the Data Dictionary Services described in 4.4.4.

 The ISO groups concentrate more on the service interfaces (APIs) among
 lower level components and utilities of the database model.

 Differences in scope and incompatibilities exist between the model being
 developed by ISO and the model approved by ANSI.  They are independently
 developing the Services Interface, and an export/import facility.

 4.4.5.3  Gaps in Available Standards

 There are two significant areas described in 4.4.4 as requirements that
 are not addressed by standards:

     - Methods to access data such as hashing and indexed sequential
       access to data is not currently standardized.  There is no
       consensus in the standards community as to whether such
       standardization would be beneficial.

     - Standardization of semantic and object oriented models have also
       not taken place, though groups like the ANSI Database system study
       group (DBSSG) are currently investigating the feasibility of
       standardization in these areas.

     - I/O Services such as screen generation.

     - Management and control of database services.  Also include all gaps
       (all services without standards).


 4.4.6  OSE Cross-Category Services

 4.4.6.1  Security

 The ability to specify logical database access control mechanisms is       e
 important to database security.                                            e


 4.4.7  Related Standards

 The standards and activities described in this subclause are related to
 the above and may also be relevant to your activities.

 There are several areas closely related to the Database area that are
 worth considering with respect to standardization.

 The first area to consider is the communications and networking area.
 Interoperability for distributed applications or the use of distributed


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.4 Database Services                                                 109






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 databases may indicate the use of communications software adhering to
 networking standards.  See 4.3 for further discussion of that area.
 (Specifically consider the following standards described in that
 subclause:

    ISO/IEC 9804.3       (OSI CCR services)

    ISO/IEC 9805.3       (OSI CCR protocol)

    ISO 8824             _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_S_I--
                         _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e
                         (_A_S_N._1)

    ISO 8825             _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_S_I--
                         _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _B_a_s_i_c _E_n_c_o_d_i_n_g _R_u_l_e_s _f_o_r
                         _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1)

 The second area to consider is transaction processing.  That area goes
 further in addressing the total requirements for distributed
 applications.  See 4.6.































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 110                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.5  Data Interchange Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _R_i_c_h_a_r_d _S_c_o_t_t


 4.5.1  Overview and Rationale

 The Data Interchange/Information Exchange components of the POSIX Open
 System Environment provide specialized support for the exchange of data
 between applications or components of applications.  Without support for
 data interchange, problems can arise when attempts are made to move data
 between different operational environments or between two related
 applications.  More specifically, data interchange problems arise in each
 of the five following situations:

     - Movement of a single application program and its associated data
       between operational environments,

     - Movement of data between cooperating application software within
       the same operational environment,

     - Movement of data between cooperating application software operating
       in differing operational environments,

     - Movement of data between related, but not cooperating, application
       software within a single operational environment, and across
       differing operational environments.

 From the global view, the data interchange components can provide the
 means to satisfy the needs in each of these situations.  These standards
 need to define physical formats, data formats, code sets, and data
 descriptions that are consistent across all implementations of the POSIX
 Open System Environment.


 4.5.2  Scope

 The data interchange component of the POSIX Open System Environment
 includes standard services, protocols, and data formats required to
 ensure that data can be interchanged between related application
 software.  Physical media formats are beyond the scope of the POSIX Open
 System Environment.









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.5 Data Interchange Services                                         111






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.5.3  Reference Model

 _________________________________________________________________________



















 _________________________________________________________________________
             Figure 4-12  -  Data Interchange Reference Model


 The Data Interchange Services relate directly to the POSIX Open System
 Environment reference model that was presented in Figure 3-1.  Figure 4-
 12 shows the components of the reference model that are significant for
 data interchange.  The reference model defines the conceptual
 relationships required to provide these facilities.  It should not be
 viewed as a description of an implementation.  The key entities within
 the figure are the Application Software, the Application Platform, and
 the External Environment.  To satisfy the data interchange service
 requirements, the POSIX Open System Environment must permit application
 software to transfer data to and from the external environment.

 The application software requests this transfer through the Application
 Program Interface.  In response to those requests, the data interchange
 components of the Application Platform handle conversions to and from
 standard formats and the transfer of the information across the External
 Environment Interface (EEI).  The EEI, which defines the format
 specifications required to support data interchange, can be divided into
 Data Description Protocols and Data Format Protocols.  Data Description
 Protocols provide a means to identify the data that is present.  Data
 Format Protocols provide the storage representation of the actual data.

 Today, this model is only partially supported by standards.  Physical
 formats are fairly well standardized.  Some work is beginning on data


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 112                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 format protocols standards, particularly in the networking area.  At this
 time, no general standards exist to support Data description protocols.


 4.5.4  Service Requirements

 This subclause details the Data Interchange Services and protocols that
 are required to support application portability and interoperability.
 Subclause 4.5.4.1 describes the API service requirements.  4.5.4.2
 describes the EEI service (i.e., protocol) requirements.

 Data interchange is one of the components of the POSIX Open System
 Environment that is now just beginning to evolve.  At this time, the
 general requirements for services are understood, but there is little
 general existing practice that can be pointed to as showing that current
 service requirements are both necessary and complete.  Most existing
 practice is limited to a specific application domain.  As a developing
 area, data interchange represents gaps in both the definition of service
 requirements and standards.  The data interchange component is, none the
 less, critical for supporting application portability and
 interoperability.  The data interchange service requirements are
 currently described to the extent possible at this time in their
 evolution.  More detail will be added in future revisions of this guide.

 4.5.4.1  Application Program Interface Services

 The API services to support data interchange need to provide the ability
 to store and retrieve data using the formats and protocols provided at
 the data interchange EEI.

 At this time little work has been directed at defining API-level service
 requirements for data interchange.  Data interchange API services need to
 provide a means to request that specific data be represented using the
 EEI services defined below.  Progress in this area is similar to the
 development of the networking area.  Initial standards defined protocols
 and only after those were in use has attention shifted to providing a
 standard mechanism for requesting those networking services.

 4.5.4.2  External Environment Interface Services

 This section identifies the EEI services required to support data
 interchange.  These services are all in the form of protocol and format
 definitions.  As shown in Figure 4-12, these protocols include:

     - Character Sets and Data Representation

     - Data Format Protocols




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.5 Data Interchange Services                                         113






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Data Description Protocols

 These protocols are required to support the exchange of information
 between application software entities, both within a single application
 platform and between application platforms.

 4.5.4.2.1  Character Sets and Data Representation

 The ability to support Character Sets and Data Representation is crucial
 to providing effective data interchange between application software
 operating under differing language and cultural conventions.  These
 services add facilities to the POSIX Open System Environment to identify
 the character set and data representations associated with textual data.
 A detailed description of the requirements in this area can be found in
 5.1.

 4.5.4.2.2  Data Format Protocols

 The data format protocols need to provide the ability to identify the
 representation of the data in a manner that is independent of the
 specific execution environment.  The data format protocol layer adds
 attributes that describe the physical characteristics of the data that
 must be known to properly retrieve the data value, given the storage
 formats that are native on the hardware/software environment where the
 data is used.  The complete attribute information required to decipher
 that data value includes:

     - Detailed storage format for the value

     - The data value in an environment-neutral format

 The data format protocols protect applications from hardware/software
 differences between environments.  Specifically, the protocols ensure
 that data remains stable when moving between environments where the
 character set, word size, or byte ordering may differ.

 4.5.4.2.3  Data Description Protocols

 Data description protocols provide the ability to share data between
 related application software entities, even if they were not specifically
 written to cooperate.  Building upon the facilities provided by the
 previous two Data Interchange EEI Services, data description protocols
 provide a means of associating a name or other identifier with the
 individual data elements in a standard manner.  This permits an
 application program to correctly identify data that was created by an
 unrelated application.  To date, most standards in this area have limited
 themselves to specific application areas and no general solution has been
 provided.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 114                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.5.5  Standards, Specifications, and Gaps

 See Table 4-6.


                 Table 4-6  -  Data Interchange Standards
 __________________________________________________________________________________________________________________________________________________
                Service                  Type     Specification      Subclause e
 ______________________________________________________________________________e

 Data Description Protocols ODA/ODIF      S     ISO 8613 Parts 1-8   4.5.5.1   e ee
                            SGML          S     ISO 8879             4.5.5.1   e ee
                            EDIFACT       S     ISO 9735             4.5.5.1   e ee
                            STEP          E     ISO DP 10303         4.5.5.2   e ee
                            EDIFACT       S     ANSI X.12            4.5.5.1   e ee
                            IGES          G     NBSIR 86             4.5.5.3   e ee
                            VHDL VHSIC    G     IEEE P1076           4.5.5.3   e ee
 Data Format Protocols      ODA/ODIF      S     ISO 8613 Parts 1-8   4.5.5.1   e ee
                            SGML          S     ISO 8879             4.5.5.1   e ee
                            CGM           S     ISO 8632             4.5.5.1   e ee
                            CGM           S     ANSI X3.122-1986     4.5.5.1   e ee
                            STEP          E     ISO DP 10303         4.5.5.2   e ee
                            EDIFACT       S     ISO 9735             4.5.5.1   e ee
                            EDIFACT       S     ANSI X.12            4.5.5.1   e ee
                            IGES          G     NBSIR 86-3359        4.5.5.3   e ee
                            VHDL VHSIC    G     IEEE P1076           4.5.5.3   e ee
                            CDIF          G                          4.5.5.3   e ee
 __________________________________________________________________________________________________________________________________________________


 4.5.5.1  Current Standards

 _O_p_e_n__D_o_c_u_m_e_n_t__A_r_c_h_i_t_e_c_t_u_r_e__(_O_D_A_)_/_O_p_e_n__D_o_c_u_m_e_n_t__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_O_D_I_F_)

 The ODA/ODIF standard (ISO 8613 Parts 1-8) provides a standard for the
 structures used to represent documents.  The ODA model defines a
 comprehensive description of a documents format.  It supports both
 reproduction of the original document and also editing and formatting of
 the document.

 Part 5 of the ISO ODA standard specifies the interchange format for ODA
 documents; specifically ODIF.  ODIF is an ASN.1 (ISO 8825) based
 presentation of the ODA document.

 _S_t_a_n_d_a_r_d__G_e_n_e_r_a_l_i_z_e_d__M_a_r_k_u_p__L_a_n_g_u_a_g_e__(_S_G_M_L_)

 SGML (ISO 8879) is a language that allows users to precisely define the
 structure of a document.  The key difference between SGML and ODA/ODIF is
 that the former provides the flexibility to define custom document types.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.5 Data Interchange Services                                         115






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _C_o_m_p_u_t_e_r__G_r_a_p_h_i_c_s__M_e_t_a_f_i_l_e__(_C_G_M_)

 CGM (ISO 8632, ANSI X3.122-1986) provides a standard means for the
 storage and exchange of computer graphics.  Graphic information is stored
 in a device- and resolution-independent fashion that can support both the
 display and the manipulation of the data.

 _E_l_e_c_t_r_o_n_i_c__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__(_E_D_I_)

 The EDI standards [ISO 9735 (EDIFACT), ANSI X.12] provide support for the
 exchange of structured business data.  EDI is typically used to transfer
 business documents such as purchase orders, invoices, promotional
 announcements, and electronic funds transfer information.

                                                                            e

 4.5.5.2  Emerging Standards

 _S_t_a_n_d_a_r_d__f_o_r__t_h_e__E_x_c_h_a_n_g_e__o_f__P_r_o_d_u_c_t__M_o_d_e_l__D_a_t_a__(_S_T_E_P_)

 STEP (ISO DP 10303) is a neutral mechanism capable of completely
 representing product data throughout the life cycle of a product.  The
 completeness of this representation makes it suitable not only for file
 exchange, but also as a basis for implementing and sharing databases of
 archiving.

                                                                            e

 4.5.5.3  Gaps in Available Standards

 4.5.5.3.1  Public Specifications

 Most standards activity in the data interchange area has been isolated to
 specialized application areas.  These activities have attempted to
 support data interchange by limiting the scope of the effort to a
 specific type of data.  These industry standards include:

                                                                            e

 _I_n_i_t_i_a_l__G_r_a_p_h_i_c_s__E_x_c_h_a_n_g_e__S_p_e_c_i_f_i_c_a_t_i_o_n__(_N_B_S_I_R__8_6_-_3_3_5_9_)

 IGES is used heavily in the exchange of graphical information between
 applications.

                                                                            e






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 116                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _C_A_S_E__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_C_D_I_F_)

 The CDIF Technical Committee is developing a data interchange format to
 serve as an industry standard for exchanging information between
 Computer-Aided Software Engineering (CASE) tools.  CDIF is an EIA-
 endorsed initiative.  It assumes that two or more tools may interface
 asynchronously with each other and will transfer information from one to
 another via ``CDIF files.''  The types of information that may be
 contained in these files is defined by the CDIF Conceptual Models.

                                                                            e

 _H_a_r_d_w_a_r_e__D_e_s_c_r_i_p_t_i_o_n__L_a_n_g_u_a_g_e__(_V_H_D_L__V_H_S_I_C_)

 The VHDL standard (IEEE P1076) defines a representation for the exchange
 of CAD representations of electronic circuits.

 4.5.5.3.2  Unsatisfied Service Requirements

 None of these standards addresses a general means to handle application
 data in a manner to ensure portability between environments.  The closest
 attempt is the effort just beginning in POSIX.8 to define a means within
 the network interface to provide data portability.  However, even this
 effort is not attempting to solve the broader issue of interoperability
 of multiple applications.  The existing standards have all evolved to
 support the interchange of specific types of data between separate
 applications.  Support for general data portability is not addressed by
 existing standard, except for ISIS, which does not appear to have caught
 on.


 4.5.6  OSE Cross-Category Services

 Not applicable.


 4.5.7  Related Standards

 The following standards are related to the services covered in this
 clause as they address some of the services described in section 4.6.4 at
 some level.  Each of these related standards are addressed fully as part
 of another service category.

  ASN.1   ISO 8824               Abstract Syntax Notation   (Clause 4.3)
          ISO 8825               ASN.1 Basic Encoding Rules (Clause 4.3)

  MHS     ISO/CCITT X.400-1984   Message Handling System (Clause 4.3)




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.5 Data Interchange Services                                         117






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          ISO/CCITT X.400-1988   Message Handling System (Clause 4.3)


 4.5.8  Open Issues

 Data interchange support must address hardware/software differences
 between environments.  The key concerns in transporting data that must be
 addressed will include the character set, word size, and byte ordering
 for the operating environment along with a accurate identification of the
 data value.

 The data portability standards adopted within POSIX Open System
 Environment need to define data formats that will enable applications to
 create data that can be used read and properly interpreted on differing
 operating environments and by other application software.




































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 118                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.6  Transaction Processing Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _B_o_b _G_a_m_b_r_e_l


 4.6.1  Overview and Rationale

 The database management clause (see 4.4) described some transaction
 processing (TP) service requirements (specific to databases).  This        e
 clause describes the complete set of transaction processing services from
 the application software point of view.  Note that transaction processing
 services have long been been regarded, variously, to be within the domain
 of databases or within the domain of operating systems and more recently
 within the domain of interconnect.  These services are more broadly
 applicable than just both of these areas, and so are treated here as a     e
 separate clause.

 Transactions (``units of work'') have boundaries (start points and end
 points) that are determined by the action of the transaction application
 program.  The transaction application program can request to either
 commit or rollback the work done in the transaction when it identifies
 the end point.  The system will complete a commit operation only if all
 operations performed during the transaction can complete successfully.
 Otherwise the system will abort the transaction (rollback the work done
 by it) and notify the transaction application program of this action.

 The following is quoted with a few editorial changes from ISO/IEC DP
 10026-1, the ISO Distributed Transaction Processing standard draft:

       A transaction is characterized by four properties:
       atomicity, consistency, isolation, and durability.  These are
       the _A_C_I_D properties.

       Atomicity implies that the operations of a unit of work are
       either all performed, or none of them are performed.

       Consistency implies that the operations of a unit of work, if
       performed at all, are performed accurately, correctly, and
       with validity, with respect to application semantics.

       Isolation implies that the partial results of a unit of work
       are not accessible, except by operations which are part of
       the unit of work.  Isolation also implies that units of work
       which share bound data are serializable.

       Durability implies that all the effects of a completed unit
       of work are not altered by any sort of failure.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.6 Transaction Processing Services                                   119






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.6.2  Scope

 This clause deals with the transaction processing services needed for a
 large number of styles of transaction processing including the following:

     - Transactional access to a single database manager on a single
       machine

     - Transaction access to nondatabase ``resource managers'' (such as
       the software managing the cash in an automatic teller machine)

     - Distributed Databases--databases spanning multiple machines, but
       accessed by application programs as if just a single database

     - Online Transaction Processing (OLTP)--the scheduling of
       ``transaction programs'' based on terminal input with consolidated
       recovery of the database updates and the terminal messages

     - Distributed Transaction Processing (DTP)--different machines
       running multiple application programs with multiple databases,
       using a client/server or conversational application-to-application
       communications paradigm

 Note that Transaction Processing Services are used in all of the above
 situations, and others too.

 Finally, it should be noted that ``transactions'' are not really
 ``messages,'' but rather ``units of work'' that may encompass multiple
 messages.  Furthermore, while traditionally ``transaction processing''
 has usually been synonymous with ``OLTP'' where so-called ``immediate
 transactions'' are the norm, other types of transactions are also
 covered:  ``batch transactions'' (where the work is done in the
 ``background'') and ``deferred transactions'' where there may be a time
 dependence on the transaction, such as a fixed start time.

 This clause addresses the current work in progress in groups such as ISO
 and others.


 4.6.3  Reference Model

 This subclause addresses the conventional Transaction Processing
 Reference Model, the POSIX OSE Reference Model (incorporating transaction
 processing considerations), and other important real world considerations
 introduced by Transaction Processing.






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 120                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.6.3.1  Conventional Transaction Processing Reference Model

 A model for transaction processing is developed here to complement the
 POSIX system model.  Current work in progress by the POSIX.11 Transaction
 Processing Working Group and other groups such as ISO/IEC JTC 1/SC21 Open
 Systems Interconnection--Distributed Transaction Processing may result in
 a Transaction Processing Reference Model more suitable than the one
 developed here.  At that time, such a model will be referenced and
 incorporated into the POSIX OSE reference model.  Until that time, the
 current model will be used as a convenient means for describing the
 services needed in this domain.

 While transaction processing services have usually been thought of as
 applying to databases, the applicability goes further.  Nonetheless, the
 description given here of the transaction processing model shows how the
 transaction processing program can view the transaction services as an
 extension of the the Database view of the POSIX OSE reference model as
 shown in Figure 4-10.  From the transaction application program point of
 view, a transaction processing system has additional capabilities that go
 beyond those provided by database systems.  These services to the
 transaction application program are provided at an API that is called the
 _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r _A_P_I.  (See Figure 4-13.)  For convenience in
 discussing the model, the provider of those services is called the
 _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r (TM).

 _________________________________________________________________________

















 _________________________________________________________________________
       Figure 4-13  -  The Conventional Transaction Processing Model


 The transaction application program requests services provided by the _T_P
 _r_e_s_o_u_r_c_e _m_a_n_a_g_e_r2) (e.g., a database manager) via the _T_P _r_e_s_o_u_r_c_e _m_a_n_a_g_e_r


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.6 Transaction Processing Services                                   121






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _A_P_I.  The transaction manager API and the TP resource manager API are
 called the _t_r_a_n_s_a_c_t_i_o_n _s_e_r_v_i_c_e_s _A_P_I and provide all the services needed
 by transaction application programs.

 The ACID properties are maintained for each managed resource by a _T_P
 _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r (_T_P_R_M), coordinated by a _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r.  The
 interface between the TP Resource Manager and the Transaction Manager
 will be called the _T_r_a_n_s_a_c_t_i_o_n _M_a_n_a_g_e_r/_T_P _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r _S_I_I (_T_M/_T_P_R_M
 _S_I_I).

 The ACID properties can be applied not only to resources such as
 databases, but also to other resources that might not be obvious.  For
 instance, a transaction that dispenses cash may wait until the cash
 dispensing machine has signaled completion before considering the
 transaction complete and updating involved accounts.  This illustration
 also shows the limits of transaction processing resource management.  The
 machine could signal completion, but a mechanical problem could prevent
 the cash from being dispensed correctly, undetected by the system.

 Besides database TPRMs and miscellaneous nondatabase TPRMs, a third class
 of of TPRMs exist:  Communications TPRMs (cTPRM).  Services provided by
 cTPRMs are used when two cooperating transaction application programs
 need to communicate with each other in the context of the same
 transaction.  At least two communications paradigms have been identified
 as beneficial to cooperating transaction applications programs:
 client/server (RPC, single request/response) and conversational (peer-
 to-peer, dialog).

 4.6.3.2  POSIX OSE Reference Model (with Transaction Processing)

 The conventional transaction processing model is shown integrated into
 the POSIX OSE Reference Model in Figure 4-14.  Because the POSIX OSE
 Reference Model does not address System Integration Interfaces (SIIs) per
 se, they are not shown in the integrated model.  What is shown are the
 transaction processing services APIs and EEIs.








 __________
  2) The term ``TP resource manager'' should not be confused with a         e
     different term, ``resource management services,'' which is a type of   e
     service described in most service category classes in this section     e
     (e.g., 4.6.4.3).                                                       e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 122                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________






















 _________________________________________________________________________
     Figure 4-14  -  POSIX OSE Transaction Processing Reference Model


 4.6.3.3  Implementation Aspects                                            e

 The POSIX OSE Reference Model does not provide for a way to expose the
 details of the Application Platform.  System Internal Interfaces (SIIs)    e
 are beyond the direct scope of this guide because they do not directly     e
 affect application portability or system interoperability.  In the         e
 Transaction Processing world, as shown in the conventional Transaction
 Processing Reference Model (see 4.6.3.1), the existence of Transaction
 Managers and multiple TP Resource Managers connected by the TM/TPRM SII
 is important.  One way to think about the real world implications of this
 is that TP Resource Managers and the Transaction Managers could both be
 implemented in the Application Platform as separate entities, connected
 to each other by the TM/TPRM SII.  This does not, however, imply that the
 two must be implemented as separate entities, though there are advantages
 to the user if they are separate.
 NOTE:  For application portability it is not required that the
 application platform actually consist of Transaction Managers and TP
 Resource Managers, but in the new age of Open Systems, there are clear
 advantages in doing so.  Two advantages seem obvious:  the ability to
 ``mix and match'' Transaction Managers and TP Resource Managers from
 different vendors; and the ability of a user to construct his/her own TP
 Resource Manager to manage particular critical resources.  A market has


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.6 Transaction Processing Services                                   123






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 already developed for ``plug compatible'' TMs and TPRMs.  All TPRMs at
 this printing are Database type TPRMs.  It is expected that a market will
 also develop for Communications type TPRMs.  It is not at all clear that
 the industry will develop other types of widely applicable TPRMs, thus
 forcing users to develop their own.  Users could use the interface
 described here to do such development work.

 This NOTE very briefly describes the services that should be provided at
 such an interface.

 The TM/TPRM interface must provide the ability of TMs and TPRMs to:
 register with each other; obtain recovery status information; pass along
 transaction identifier information; rollback, prepare to commit, and
 commit the transaction.  The interface must provide for the needs of the
 full range of transaction processing including distributed transaction
 processing with multiple TPRMs.

 Finally it should be noted that the industry recognizes the need for
 standardization of components as well as the standardization of
 portability and interoperability.  At least one industry group is
 standardizing and several vendors are implementing products utilizing an
 interface as described here.


 4.6.4  Service Requirements

 Services provided via the Transaction Processing Services API are
 described in 4.6.4.1.  Services to enable the distribution of transaction
 processing are described in 4.6.4.2.  General services, mostly performing
 administrative functions, are described in 4.6.4.3.                        e

 4.6.4.1  Application Program Interface Services

                                                                            e

 The Transaction Services API provides various services to the application
 programmer:

    Transaction Demarcation

        - Indicate the start of a transaction.

        - Indicate a transaction has ended successfully (commit) or
          unsuccessfully (rollback).

        - Indicate the beginning and ending of nested ``subtransactions''
          whose commitment is independent of the ``parent transaction''.
          (Nested within a parent transaction can be multiple
          subtransactions.  Subtransactions are independent of each other,


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 124                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          and whether subtransactions commit or not does not affect the
          commitment of the parent.)

        - Suspend and resume transaction mode (to do work which is not be
          committed or rolled back when the transaction is completed).
          This can be thought of as nesting nontransaction work within a
          transaction.

                                                                            e

    Communications Between Transaction Application Programs

        - Call another transaction application program (possibly remote)
          within the context of a transaction.

        - Open a dialog and send and receive ``messages'' to and from
          another transaction application program (possibly remote) within
          the context of a transaction.

       NOTE:  The above services provide ``Distributed Transaction
       Processing.''                                                        e

    Terminal Communications

        - Send and receive messages to and from terminals within the
          context of a transaction (i.e., messages sent to terminals are
          not to be actually delivered unless the transaction commits).

    Transaction Program Scheduling

        - Cause to be started another transaction application program
          outside of the context of this transaction.  Involved here are
          two transactions:  one starts the other.  The actual scheduling
          of the second transaction can be dependent on the completion or
          not of the original transaction.

    Transaction Message Queuing

        - Define a ``message'' (based, possibly, on screen input from the
          end user) that, from the application point of view, precisely
          defines a unit of work to be done by this transaction or another
          transaction.

        - ``Send'' a message to another transaction application program.

        - Retrieve the next message (and then act upon it)

        - Prioritize and associate start times with messages



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.6 Transaction Processing Services                                   125






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          NOTE:  The actual handling of messages can be dependent on the
          completion or not of the original transaction.

 NOTE:  Several of the above services are similar to but semantically
 different from similar sounding services in other clauses of this
 section.  They are listed here because they are ``transactional''; i.e.,
 the concept of a transaction and the ACID properties are provided by
 these services.

 TP Resource Managers provide services usable by the transaction
 application program and are made visible by the TP Resource Manager API.
 An example of this is the Database API services; see 4.4.4.1.              e
 NOTE:  TP Resource Managers, in general, ``protect'' a critical resource.  e
 Databases are good examples of TP resource managers where the resource     e
 actually being protected is the data, for example, of an enterprise.       e
 Often the data of an enterprise reflects the amount of a real resource     e
 such as cash holdings.  In this case a tangible resource is indirectly     e
 protected by a TP resource manager.  The importance to the enterprise in   e
 insuring that the data (quantifying money) is accurate should be obvious.  e
 Other TP resource managers, on the other hand, could protect an actual,    e
 tangible resource.  An example of such a TP resource manager is the        e
 program that controls the cash drawer of an automated teller machine.      e
 The resource protected is the cash in the drawer.  The actual application  e
 program interface of the TP resource manager protecting that resource      e
 could include the ability to reduce the amount of money in the drawer (by  e
 pushing it out of the machine).  A transaction application program using   e
 two TP resource managers (a conventional database manager that keeps       e
 track of the balance in accounts, and the teller machine's cash drawer TP  e
 resource manager) would want to insure that the two TP resource managers   e
 decrement both the cash and the balance of the correct account in the      e
 context of a single transaction (i.e., with the ACID properties.)          e

 The TP Resource Manager API, then, generally provides the following        e
 services:                                                                  e

     - Increment or decrement a valuable resource by a certain amount.      e

     - Determine the amount of a valuable resource that remains.            e

 Specific capabilities for the very wide variety of specific TP resource    e
 managers, cannot, of course, be documented here.                           e

 4.6.4.2  External Environment Interface Services                           e

 When two or more machines are involved in the same transaction, the        e
 following service is required:                                             e

     - The ability for two application platforms to interoperate with each  e
       other (pass along global transaction identifiers, participate with   e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 126                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

       each other in commitment process, participate with each other in     e
       recovery).                                                           e

                                                                            e

 4.6.4.3  OLTP Resource Management Services

 The services listed in this subclause are not provided by application
 program interfaces or external environment interfaces.

     - Management Services -- Control the operation of the transaction
       processing services, including the ability to assign dispatching
       priorities to individual transaction application programs.

     - Monitoring Services -- Collect data on resource utilization for
       purposes such as performance analysis and accounting (data on
       utilization of the transaction processing services resources:
       processes, connection pools, ...).

     - Modeling Services -- Predict the system resources needed to process
       a given transaction processing workload.

     - Directory/Namespace Services -- Map names to addresses.

     - Recovery/Restart Services -- Recover and restart transactions
       involving one or more transaction application programs using one or
       more TP Resource Managers.

     - Test Services -- Automatically generate tests for workload
       simulation, etc.

     - System Configuration Services -- Replace or add transaction
       application programs without the need to shut down the execution
       environment.

                                                                            e


 4.6.5  Standards, Specifications, and Gaps

 There are currently three transaction processing standards development
 activities, either completed or in the draft stage.  Table 4-7 summarizes
 the service requirements provided by the various standards.

 Table 4-8 summarizes the applicability of the various standards to the
 various programming languages supported by the POSIX Open System
 Environment.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.6 Transaction Processing Services                                   127






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS


              Table 4-7  -  Transaction Processing Standards
 __________________________________________________________________________________________________________________________________________________
           Service              Type        Specification        Subclause  e
 _________________________________________________________________________  e

 API Services                    E     IEEE P1003.11             4.6.5.2    e     ee

 EEI Services                    E     ISO/IEC 10026-1, -2, -3   4.6.5.2    e     ee

 Resource Management Services    G     -                         4.6.5.3    e     ee
 __________________________________________________________________________________________________________________________________________________



     Table 4-8  -  Transaction Processing Standards Language Bindings
 __________________________________________________________________________________________________________________________________________________
 Standard        LIS       Ada        APL        BASIC        C       C++   e
 ________________________________________________________________________   e

 POSIX.11         E                                           E             e

 Standard     COBOL     C-LISP     Fortran     Pascal      PL/1     Prolog  e
 _________________________________________________________________________  e

 POSIX.11                                                                   e
 __________________________________________________________________________________________________________________________________________________  e
 NOTES:  LIS -- Language-independent specification is available.            e

 Ada, APL, BASIC, -- Language-dependent specifications exist.               e

 S, E, G -- Standard, Emerging Standard, Gap                                e


 4.6.5.1  Current Standards

 None.                                                                      e

 4.6.5.2  Emerging Standards

 _O_S_I__D_i_s_t_r_i_b_u_t_e_d__T_r_a_n_s_a_c_t_i_o_n__P_r_o_c_e_s_s_i_n_g__(_D_T_P_)

       ISO/IEC DIS 10026-1
       ISO/IEC DIS 10026-2
       ISO/IEC DIS 10026-3

 These standards, developed by ISO/IEC JTC 1/SC21/WG5, deal expressly with
 the OSI services and protocols for transaction mode communications in an
 OSI environment.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 128                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 These standards provide for some of the communications services described
 in 4.6.4.1.

 _P_O_S_I_X_._1_1__P_O_S_I_X__T_r_a_n_s_a_c_t_i_o_n__P_r_o_c_e_s_s_i_n_g

       POSIX.11

 The POSIX.11 working group, formed in 1989, is chartered to work on a
 profile for Transaction Processing within the POSIX OSE.  In the process
 of developing that profile, it has identified a number of gaps in the
 standards coverage and is in the process of proposing base
 standardization activities to address those gaps.  Specifically, P1003.11
 is currently working on the following services identified earlier:

     - Transaction Manager (TM) Services provided at the Transaction API.

     - Services provided at the Transaction Manager/TP Resource Manager
       (TM/TPRM) SII.  A typical TPRM is a database manager (e.g., SQL).

 POSIX.11 is working to assure that POSIX Transaction Processing work is
 consistent with the emerging work of OSI DTP (cited above), certain
 ongoing work of X/Open TP, several related POSIX activities (POSIX.1 {2},
 POSIX.4, POSIX.8) and the work of ANSI X3T5.5 (RPC).

 4.6.5.3  Gaps in Available Standards

 4.6.5.3.1  Public Specifications

 Existing standards and emerging standards do not adequately address all
 the requirements identified earlier.  While POSIX.11 is addressing some
 of the gaps, there are many other gaps still not being addressed by
 formal standards committees.  Most notable is the work of X/Open TP.
 While not formally a standards making body, it is addressing most of the
 gaps, and its output will be potentially useful as the basis of a formal
 standard.

 _X_/_O_p_e_n__T_P

 This group published an ``Online Transaction Processing Reference Model''
 in 1987 and in 1990 published ``Preliminary Specification--Distributed
 Transaction Processing: The XA Specification.''  The group is studying
 the use of OSI DTP, two-phase commit, and global transaction identifiers.
 The group is also actively exploring APIs in support of peer-to-peer
 distributed transactions.

 The work of this group addresses several of the services addressed in
 this clause, including transaction demarcation and conversation services.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.6 Transaction Processing Services                                   129






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Consideration is also being given to allowing alternative
 interoperability standards including proprietary mechanisms.  Additional
 APIs are being defined by X/Open TP to facilitate this.

 4.6.5.3.2  Unsatisfied Service Requirements

 Other than the work of X/Open TP, the following areas are not currently
 being addressed by standardization activities:  communications, terminal
 communications, program scheduling, message queueing, management,
 monitoring, modeling, directory/namespace, recovery/restart, test, and
 system configuration.


 4.6.6  POSIX OSE Cross-Category Services

 Not applicable.


 4.6.7  Related Standards

 _C_C_R

 The following standards relating to commitment are related to the ISO/IEC
 DIS 10026 series and are referenced in DIS 10026:

       ISO/IEC DIS 9804-3
       ISO/IEC DIS 9805-3

 See 4.3 for more information.

                                                                            e

 _S_Q_L__S_t_a_n_d_a_r_d__D_a_t_a_b_a_s_e__L_a_n_g_u_a_g_e

 The following standards for SQL also provide transaction demarcation
 services for relational database access:

       ANSI X3.135.1 (ISO 9075, FIPS 127)
       ANSI X3.168

 See 4.4










              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 130                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.7  Graphical Window System Services                                      e

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _M_a_r_t_i _S_z_c_z_u_r _a_n_d _R_u_t_h _K_l_e_i_n

 _E_d_i_t_o_r'_s _N_o_t_e:  _V_a_r_i_a_t_i_o_n_s _o_n _t_h_e _t_e_r_m ``_h_u_m_a_n _c_o_m_p_u_t_e_r _i_n_t_e_r_a_c_t_i_o_n'' _a_n_d  _e
 _H_C_I _i_n _t_h_i_s _c_l_a_u_s_e _h_a_v_e _b_e_e_n _r_e_p_l_a_c_e_d _g_l_o_b_a_l_l_y _b_y ``_g_r_a_p_h_i_c_a_l _w_i_n_d_o_w       _e
 _s_y_s_t_e_m_s'' _w_i_t_h_o_u_t _f_u_r_t_h_e_r _d_i_f_f _m_a_r_k_s.  ``_H_u_m_a_n _u_s_e_r'' _h_a_s _a_l_s_o _b_e_e_n        _e
 _r_e_p_l_a_c_e_d _b_y ``_u_s_e_r.''                                                      _e


 4.7.1  Overview and Rationale

 The graphical window system interface is a key component of computer       e
 systems that support direct user-machine interaction.  Until recently,     e
 most computer operating systems interpreted commands that were typed in
 from the keyboard of an alphanumeric computer terminal.  Special purpose
 applications, such as those for CAD/CAM, have always presented user
 interfaces based on series of menus or pointing at visual displays with
 tablets and lightpens.  The availability of low-cost bitmapped graphic
 workstations and personal computers has led to the proliferation of
 graphical user interfaces (GUIs), windowing technologies, generic
 commands, and an assortment of selection techniques (e.g., mouse, track
 ball, tablets).  In several of these technologies de facto standards are
 emerging and becoming informally accepted by the user community, and with
 more frequency, mandated for use in systems being developed within
 government agencies and private industry.  The primary motivations for
 considering graphical window system standards and their relation to POSIX
 standards include:

     - The existence and popularity of windowing systems

     - The requirement for development of applications that take advantage
       of the windowing system environment

     - The requirement of many users and manufacturers for a basic
       consistency in the presentation and behavior of graphical window
       systems across multiple graphics platforms

 As the windowing system technology evolves within the graphics
 environment, the differences between windowing services and graphic
 services becomes less distinct.  The distinction for purposes of this
 document is that graphic services are associated with providing general
 purpose interfaces for creating virtually any kind of two- and three-
 dimensional graphics (e.g., GKS for 2-D and PHIGS for 3-D).  Graphical
 window system services certainly utilize graphic technologies, but are
 limited to providing graphics related to window-based user interfaces and
 specifications on how users may interact with an application within a
 window environment.  The graphic services are addressed independently in
 4.8.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  131






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

                                                                            e


 4.7.2  Scope

 Standards and standards initiatives in the graphical window system
 interface area cover a wide area, ranging from keyboard layout to screen
 management.  In this clause, the following specific standards are
 considered:

     - Protocols for window management on a local or remote display device

     - Application Program Interfaces (API) for such protocols

     - Graphical window system drivability features that define a common
       subset of ``look and feel''; i.e., appearance, screen positioning,
       and behavior of graphical window system objects within windows on a
       graphic screen

     - Language-independent functional specifications and appropriate
       associated language bindings for the display, manipulation, and
       management of interaction objects within windows on a graphic
       screen

     - Command-language interfaces that may be entered interactively by
       the user or retrieved from a stored procedure.

     - Language-independent functional specifications and appropriate
       associated language bindings required to support character (non-
       bitmapped) terminals.

     - Language-independent functional specifications and appropriate
       associated language bindings for the translation, manipulation, and
       management of command statements (or messages).

 Standards relating to the following are not considered:

     - Graphics; see 4.8.

     - Keyboard layout (out of scope for graphical window system services)

     - Network transport protocols; see 4.3.

     - Hardware device interfaces (out of scope for graphical window
       system services)






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 132                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.7.3  Reference Model

 This subclause identifies the entities and interfaces specific to the
 construction of a graphical window system architecture.  This
 architecture is consistent with, and extends the architecture of, Section
 3.  As illustrated in Figure 4-15, the interface components involved in
 the user interface process are divided into two groups, called the
 external environment interface (EEI) and the application program
 interface (API).

 _________________________________________________________________________

























 _________________________________________________________________________
                 Figure 4-15  -  Windowing Reference Model


 The EEI is concerned with the communication with the user via the
 physical graphical window system devices (e.g., keyboard terminal, mouse,
 display screen).  The applicable EEI standards are driven primarily in
 support of user and data portability across different application
 platforms.  Standards and guidelines are intended to define a minimal set
 of commonality in graphical window systems, which will eliminate problem
 areas such as:




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  133






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Error provoking inconsistencies

     - Misleading expectations about the results of user actions

     - Gross inconsistencies in the high level user model or metaphor

     - Incompatible motor control tendencies

 The drivability concept derives its name from the concept of ``driving''
 an interface.  A frequently cited analogy is the automobile.  Having a
 standard location for the clutch, brake, accelerator pedals, ignition
 key, and steering wheel allows a driver to move between car models with
 relative ease (until he/she has to roll down the window, turn on the
 lights or windshield wipers!)  Similarly, the EEI drivability guidelines
 will provide standards for graphical window systems that will ensure ease
 of moving between application platform models.  For example, which mouse
 click causes an interaction object (e.g., radio button) to be selected or
 how a scroll bar should behave would be candidates for standard EEI
 specification.

 The API is concerned with the interface between the application semantics
 and the graphical window system services.  It is the interface between
 the application software and the application platform and is defined
 primarily in support of application portability.  These services provide
 functions for creation and manipulation of visual display objects such as
 menus, buttons, scrollbars, and dialog boxes.  In addition, these
 functions allow information about user actions to flow back to the
 application software; for example, when the user has selected an item
 from a menu.  This information about user actions is known as an event.
 Applications that require communication with the user are inherently
 event-driven.  That is, associated with an application's dialog window
 (i.e., a window in which a user response is expected) is a main event
 loop waiting for the user to make a selection that will trigger an
 operation to be performed by the application.

 The API will support a specific user interface policy, which will define
 the application's ``look and feel.''  Although the specific look and feel
 need not be standard across application platforms (i.e., different
 implementations of the API may have unique styles) the API definition
 shall ensure that the application software can be ported across POSIX
 platforms; and the API shall support the EEI drivability guidelines,
 enabling users to easily operate the application across platforms.

 Elements of the graphical window system architecture are Application
 Software Elements, Application Program Interface (API) elements, and
 External Environment Interface (EEI) elements.  These elements are linked
 by the use of common concepts and definitions associated with the
 graphical window system entities, interfaces, services, and standards.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 134                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.7.3.1  Application Software Elements

 Application Entity Elements include:

     (1)  Window System Server

          The Window System Server provides a function that handles
          communication connections from clients, demultiplexes graphics
          requests onto the screens, and multiplexes input back to the
          appropriate client.  Applications and other programs that use
          basic windowing services are called ``clients.''  Many clients
          may talk to the same server.  All application requests to write
          to the screen must go through the server via the basic windowing
          services.  The server is independent of operating system,
          programming languages, or network communication.

     (2)  Window Manager

          A Window Manager provides a uniform method for manipulating
          windows, which includes a basic set of window management
          capabilities that allow for development of alternative and/or
          user-preferred window managers.  Required graphical window
          system capabilities shall include, but are not limited to:

           - Resize window

           - Move window

           - Push/pop window to top/bottom

           - Shrink window to a reduced visual representation of window
             (i.e., frequently referred to as an icon of the window)

     (3)  Local and Remote Applications

          These applications are clients that provide the functions
          required to perform the specific task(s) that the user needs to
          achieve (e.g., spreadsheets, scientific analysis systems, CASE
          tools, process and control tasks.)

 4.7.3.2  Application Program Interface (API) Elements

 The API are language binding specifications that define the services
 available to the application programmer.  API Elements are: basic window
 services, toolkit window services, and dialog services.






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  135






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.7.3.3  External Environment Interface (EEI) Elements

 The EEI elements are specifications (and in some cases, aspects of
 physical objects) that define how the application platform interacts with
 the external world.  Note that application software, as defined here,
 interacts with the outside world only via the application platform.

 External Environment Interface Elements include:

     - Display Device Specifications

     - Data Protocol Format

     - User Drivability Guidelines (e.g., ``look and feel'' of window
       interface)

     - Keyboard Device Specification

     - Selection Device Specification (e.g., mouse, graphics tablet, touch
       screen)

     - Command-language Definition (syntax and semantics guidelines)


 4.7.4  Service Requirements

 Graphical window system services provide a controlled interface between
 the application-specific software and the user-interface-specific
 software, allowing each to be designed and implemented separately.  Users
 of these services include all POSIX system users and those charged with
 maintaining the processor and graphical window system communication.  A
 common, standardized graphical window system for applications should be    e
 available to users across all POSIX Open System Environments.

 Services shall support raster (i.e., bitmapped) graphics displays.
 Methods for supporting vector graphics displays can be addressed, but are
 not mandatory.

 4.7.4.1  Application Program Interface Services

 Application services include those services made available to the
 application developer to separate the application functions from the
 graphical window system functions as much as possible.  They include such
 areas as screen management, windowing, and user input device services.

 These standard services support requirements for application portability,
 software commonality, application interoperability and data
 communications transparency.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 136                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 A programmer may access the following services for an application via      e
 language bindings.

 4.7.4.1.1  Basic Window Services

 The basic window services, callable from client applications, support a
 window-based user interface.  They should be based on a ``client-server''
 model.  The server is a program that handles communication connections
 from clients, demultiplexes graphics requests onto the screens, and
 multiplexes input back to the appropriate client.  Many clients may talk
 to the same server.  All application requests to write to the screen must
 go through the server via the basic windowing services.

 The major functional areas are:

     - Window Management

     - Presentation Management

     - Event Handling

     - Error Handling

     - Interclient Communications

     - Input Device Management: Keyboard, Pointing Device

     - Screen Management

     - User Preferences Management

     - Server Connection Management

 The following functions are available under each functional area.

 _W_i_n_d_o_w__M_a_n_a_g_e_m_e_n_t

 Functions available for Window Management are:

     - Create a window, map a window onto the screen, delete a window
       (includes support for character-based emulator window)

     - Manipulate a window (move, resize, change view precedence)

     - Manipulate window attributes (set, get, change; attributes may be
       related to appearance, redraw performance, event handling, or
       change authority)




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  137






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Seize and relinquish control over the Server for display purposes
       (permits uninterrupted client output; output requests from other
       clients will be queued and displayed later)

 _P_r_e_s_e_n_t_a_t_i_o_n__M_a_n_a_g_e_m_e_n_t

 Functions available for Presentation Management are:

     - Associate data with a window (context manager functions and
       association table functions)

     - Manipulate the graphics context for a given object (create a
       graphics context, obtain current graphics context, change graphics
       context)                                                             e

     - Get and set fonts (load font, list fonts, unload font)               e

     - Draw graphics primitives (draw arc, draw line, fill rectangle,
       clear rectangular window, clear entire window)                       e

     - Manipulate window cursors (create, destroy, assign, change)          e

     - Draw text and obtain text metric information

 _E_v_e_n_t__H_a_n_d_l_i_n_g

 The basic window services support application requirements to respond to
 the user's actions, rather than forcing the user to respond to the
 application in a rigid, serialized manner.  This requirement necessitates
 that a program either (1) be capable of handling any one of a number of
 events at any single point in time, or (2) attach a routine to each event
 to be called automatically when that event occurs.  There is a separate
 set of events for each window used by the application.  An application
 selects the events for a particular window, maps the selected events to
 the window, and reads events from the event queue as they occur.  There
 are three major types of events:

     - Input device events (button press event, keypress event)             e

     - Window management events (window exposure event, colormap event)     e

     - Client message events (selection data transferred (by another
       application) event, private interclient communication event)         e

 Functions available for Event Handling are:

     - Select events




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 138                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Map events to a window

     - Get information about events

     - Send events

 _E_r_r_o_r__H_a_n_d_l_i_n_g

 Functions available for Error Handling are:

     - Get error message

     - Get error description

     - Set error event handler routine

 _I_n_t_e_r_c_l_i_e_n_t__C_o_m_m_u_n_i_c_a_t_i_o_n

 The basic window services are required to be network transparent to an
 application or client.  This means that an application on one host may
 write to the display screen connected to another host without being aware
 that networking is involved.  The basic window services handle the
 network connections and follow the protocols necessary for the
 application to interact with the display.  This convention allows
 redistribution of applications in a networked system with no effect on
 the application software.  Therefore, an application client cannot assume
 that another client can open the same files or seize the same processing
 environment.  Interclient communication via the server has three forms:

     - Properties

       Clients may associate arbitrary information with a window;
       generally used for communication between a client and the window
       manager.

     - Selections

       Selections are selected by the user out of one client's window,
       then ``sent'' to another client and displayed in the second
       client's window.

     - Cut Buffers

       Cut Buffers are a specialized form of communication.  It is
       possible to receive notification when a cut buffer (property) is
       set.

 Functions available for Interclient Communication are:



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  139






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Manipulate window properties (list, delete, change, get)             e

     - Set and get selections

     - Manipulate cut buffers

 _I_n_p_u_t__D_e_v_i_c_e__M_a_n_a_g_e_m_e_n_t

 Functions available for Input Device Management are:

     - Receive keyboard input and pointing device button events

     - Gain exclusive control of keyboard or pointing cursor

     - Track the pointing cursor

     - Change Server-wide keyboard mappings

     - Set and get keyboard and pointing device preferences

 _S_c_r_e_e_n__M_a_n_a_g_e_m_e_n_t

 Functions available for Screen Management are:

     - Manipulate color using colormaps (copy, change, install, deinstall,
       get default)                                                         e

     - Get, display, and manipulate bitmapped screen images

     - Screen saver functions (blanking screen on idle)

     - Retrieve display information (default colormap, number of display
       planes, screen width and height)                                     e

 _U_s_e_r__P_r_e_f_e_r_e_n_c_e_s__M_a_n_a_g_e_m_e_n_t

 The services and data structures used for managing user preferences are
 provided and collectively referred to as User Preferences Management.      e
 There may be up to four sets of options that need to be read and merged:

     - The user's defaults stored in the root window's user resource
       manager property

     - The user's defaults stored in a user's defaults file

     - The application program's defaults

     - The command line arguments



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 140                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 Functions available for User Preferences Management are:

     - Set and get preference data

 _S_e_r_v_e_r__C_o_n_n_e_c_t_i_o_n__M_a_n_a_g_e_m_e_n_t

 Functions available for Server Connection Management are:

     - Control access to the Server [add host to the access control list
       (ACL), list ACL, disable ACL]                                        e

     - Connect and disconnect a client from a Server (and the display
       controlled by the Server)

     - Obtain Server implementation information

     - Flush output buffer to Server and wait for Server to process all
       events in the output buffer

 4.7.4.1.2  Toolkit Window Services

 The Toolkit Window services provide a mechanism for runtime access to a
 library of visual objects.  A visual object is a graphical display object
 (i.e., interaction object) with associated software that receives input
 from users (typically via a keyboard and a pointing device) and
 communicates with applications and other visual object software.  The
 graphical representation of a visual object can be modified to reflect
 the results of application processing.  Examples of visual objects are
 graphical push buttons, check boxes, and editing boxes.  (Note: The term
 used within the X Window System community to define visual objects is
 ``widgets.'')

 Toolkit Window services are provided for two reasons:

     - To allow application software to directly utilize a visual object
       library

     - To allow application-specific visual objects to be created and
       added to the widget library (Note:  creating a visual object
       includes writing software that uses the Toolkit services)

 Therefore, Toolkit services may be logically divided into two categories,
 with some overlap:  Visual Object Interface Services, which are called by
 an application or dialog service, and Visual Object Programming Services,
 which are called by the visual object software.

 An application may use Toolkit Window services to:




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  141






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Perform toolkit initialization/exit

     - Set up visual object resources

     - Create/delete a visual object

     - Display a visual object

     - Add/remove application-specific routines to be called by a visual
       object (event callbacks)

     - Retrieve/modify the state of a visual object

     - Turn control over to the toolkit for user input processing

 A visual object software program may use Toolkit Window services to:

     - Manage child visual objects (a child visual object is a visual
       object that is displayed inside of another visual object)

     - Manage window events, timer events, and file input events

     - Handle visual object geometry (sizing, positioning, child visual
       object placement)

     - Handle user input

     - Manage visual object resources

     - Translate an event into an action

     - Manipulate graphics contexts

     - Manipulate pixmaps (pixel arrays--used to display a graphical
       object by turning pixels on and off)

     - Manage memory associated with graphical window systems

     - Handle errors associated with graphical window systems

     - Allow inter-visual object communication (via the selection
       mechanism)

     - Initiate other visual object routines (visual object event
       callbacks)

     - Initiate application-specific routines that have been associated
       with the visual object by the application (application event
       callbacks)


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 142                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.7.4.1.3  Dialog Services

 Dialog services provide functions to support high-level graphical window
 system management for applications with the primary goal of delivering
 user inputs to the application program and application-driven information
 to the user.  The dialog services allow for a separation of the user
 interface specifications from the application program.  For example,
 there are many applications that are not concerned with whether a user
 entry object is a pull-down menu or a scrollable list.  These
 applications are only interested in what the user specified or selected
 from the user entry object (i.e., the parameter value), which will then
 trigger some action by the application.  To support this notion, a single
 dialog function might be specified for displaying a window made up of a
 composite of visual display objects, such as radio buttons, text key-in
 objects, and scrollable text lists.  The application program does not
 need to manage or understand what the look, location, or visual feedback
 of any of these items will be.  The dialog function has access to the
 presentation information required to display the specified window and it
 handles the display of the application specified window.  Another dialog
 service would provide a high-level event loop that returns the user
 specified input as an application parameter value.

 The services provide simplicity over the degree of freedom available in
 Basic and Toolkit Window Services.  Most User Interface Management
 Systems (UIMSs) provide dialog services to fulfill their requirement of
 separation of user interface from application software.

 These services are subdivided into:

     - Window services: provide services used to initialize the window
       service, create and delete windows with predefined associated
       visual objects, and manipulation of the pointing cursor.  They
       include services that allow the application to communicate directly
       with the user via modal or modeless windows.

     - Visual object manipulation services: provide services used to
       access the graphical window system designed by the application
       designer, display the visual objects defined by the graphical
       window system, and associate them with application-tied inputs and
       outputs.

     - Event control services: provide services to allow the application
       to define a set of events and handle triggered events in one of two
       ways:

        +o Wait on the occurrence of any event, processing triggered events
          one at a time from an input queue (event-driven method)




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  143






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

        +o Attach to each event a function that is automatically executed
          when the event is triggered (callback method)

 4.7.4.2  External Environment Interface Services

 These services provide support for the actual elements with which the
 user physically interacts.  These functions provide services in three
 areas:

     - Graphical window system:  provides definition of the presentation
       and behavior of the visual display objects, command language
       definition (syntax and semantics), specifications related to
       keyboards, selection devices, audio and video input/output devices.

     - Information Interfaces: provides specification of user resource
       data formats, containing presentation and action information
       pertaining to visual display objects.

     - Network Interfaces: provides protocol services for data transport,
       which is basically the bottom six layers of the OSI model

 4.7.4.3  Interapplication Entity Services

 These services provide support for general conventions and specifications
 for interaction between graphical window system components.  The services
 provide support for generalized network/multisession services, such as
 message handling between graphical window system components, intermediate
 language definition, and a standard definition of the format used for
 saving the presentation, behavior, and action information about graphical
 window system objects.

 4.7.4.4  Windowing Resource Management Services

 These services provide general management functions across the graphical
 window system components, which include system administration-oriented
 functions (i.e., management of graphical window systems within the scope
 of the administrator, such as setting up defaults and user customization
 functions.  For instance, it is important to allow reconfiguration and
 addition of terminals and displays without affecting the application
 interface.)  These resource management services are independent from the
 OLTP Resource Management Services defined in 4.6.4.3.

 A standard definition of the format used for saving the presentation,      e
 behavior, and action information about graphical window system objects     e
 would provide a vehicle for exchanging graphical window system             e
 information between software tools, such as User Interface Management      e
 Systems (UIMSs) and Interface Design Tool (ITDs).                          e




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 144                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.7.5  Standards, Specifications, and Gaps

 Standards that relate to the user reference model presented earlier are
 considered here.  Related standards that might be relevant for one or
 more of the interface components will also be mentioned.

 4.7.5.1  Current Standards

 No current international or national standards exist for the graphical
 window system services, primarily due to the recent emergence of the
 windowing technology.  However, several standard activities are underway
 and referenced under 4.7.5.2.


                     Table 4-9  -  Windowing Standards
 __________________________________________________________________________________________________________________________________________________
             Service                Type          Specification           Subclausee
 __________________________________________________________________________________e

 Basic Window Services               G     X Window System (X-lib)        4.7.5.3  e       ee
                                     E     ANSI X3K13.6                   4.7.5.2  e       ee

 Toolkit Window Services             G     X Window System (Xtk)          4.7.5.3  e       ee
                                     E     ANSI X3K13.6                   4.7.5.2  e       ee
                                     E     IEEE POSIX.2                   4.7.5.2  e       ee
                                     E     IEEE POSIX.1 {2}               4.7.5.2  e       ee

 Dialog Services                     G     -                              4.7.5.3  e       ee

 EEI Services                        E     ANSI X3V1.9                    4.7.5.2  e       ee
                                     E     ISO/IEC JTC 1/SC18/WG19        4.7.5.2  e       ee
                                     E     ANSI HSF-HCI                   4.7.5.2  e       ee
                                     E     ISO TC159/SC4/WG5              4.7.5.2  e       ee
                                     E     P1201.2                        4.7.5.2  e       ee

 Interapplication Entity Services    G     X Window System (X protocol)   4.7.5.3  e       ee

 Window/Character Resource           G     -                              4.7.5.3  e       ee
       Management Services                                                         e
 __________________________________________________________________________________________________________________________________________________


 4.7.5.2  Emerging Standards

     - ANSI X3K13.6.  Currently developing an X Protocol standard.

     - ANSI X3V1.9.  User-System Interfaces and Symbols:  Working on a
       ISO/IEC Standard 9995, Keyboard Layouts for Text and Office
       Systems.  Also working on the Voice Messaging User Interface Forum


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  145






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

       (VMUIF).  This is a mirror standards effort with ISO/IEC
       JTC 1/SC18/WG19.

     - ISO/IEC JTC 1/SC18/WG19.  User-System Interfaces and Symbols.
       Working on developing standards for user interfaces and symbols
       associated with text and office systems.

     - ANSI HFS-HCI.  Working on drafts on the design process, information
       presentation, forms-based dialogs, and window-based interaction.

     - ISO TC159/SC4/WG5.  Software Ergonomics and Man-Machine Dialog:
       Working on developing parts of the ISO Standards 9241, Ergonomics
       of Visual Display Terminals.  Their areas of concentration are
       software ergonomics, dialog principles, dialog styles, methods for
       evaluating software usability, coding and formatting of
       information, and terminology

     - IEEE P1201.  Application and User Portability:  Chartered to
       develop standards that facilitate application and user portability
       in the X Windows environment.  P1201.1 is involved in defining a
       set of virtual toolkit services that would be independent of any
       windowing system.  P1201.2 is involved in defining drivability
       guidelines.

     - ANSI CODASYL.  Working draft available for Forms Interface
       Management Systems (FIMS), which covers the interface between a
       programming language and any form fill-in application on a computer
       or terminal screen.

 4.7.5.3  Gaps in Available Standards

 There is a de facto standard for the base window system.  The X Window
 System windowing protocol and the Xlib functional interface to the
 protocol were developed at Massachusetts Institute of Technology.
 Development is continuing under the aegis of the X Consortium, a group of
 interested parties in the computer industry and computer manufacturers.
 Relevant documents from the X Consortium are ``X Window System Protocol,
 X Version 11,'' ``Xlib - C language X Interface,'' ``X Toolkit Intrinsics
 - C Language Interface,'' and ``Bitmap Distribution Format 2.1.''

 The X Window System protocol and functional interface are considered to
 be de facto standards in the base window system area because of their
 widespread adoption by major computer vendors and industry groups.

 Within the government, the National Institute of Standards and Technology
 (NIST) issues Federal Information Processing Standards (FIPS) that
 require purchases made by the United States Government to adhere to
 certain standards.  NIST has adopted the X Window System Version 11
 Release 3's X Window System protocol, Xlib, Xt Intrinsics, and Bitmap


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 146                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 Distribution Format as FIPS 158.  This is a noncompulsory (i.e.,
 voluntary) standard.

     - Object Definition File Format:  There are no standards addressing
       the format used for describing the ``look and feel'' of graphical
       window system objects.

     - Toolkit Services

     - Dialog Services

     - Interapplication Entity Services


 4.7.6  OSE Cross-Category Services

 4.7.6.1  Security

 The security aspects of graphical window systems and include:              e

     - Authentication of person at login

     - Authentication of person when a service request is made to a client
       application

     - Provisions for visual labeling of sensitive material

     - Option selections available in support of sensitive activities

     - Prevention of moving data (cut/past) from a more protected security
       environment to a less protected environment


 4.7.7  Related Standards

 Currently, the basic windowing services provide a certain level of
 graphics functionality, but the existing and proposed graphics standards
 (e.g., PHIGS, GKS) provide a much more comprehensive solution to graphic
 support.  As the graphics and windowing technologies evolve, this
 distinction between the windowing and graphics services will continue to
 be blurred.  For instance, proposals are already being developed that
 provide extensions to the X Window System that support 3-D graphics
 (i.e., PEX, PHIGS EXtensions), and implementations of GKS are currently
 available that use the X Window System to create the graphics.







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.7 Graphical Window System Services                                  147






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.7.8  Open Issues

     - Audio input/output

     - Video input/output

     - Security

     - Desktop.  The Desktop, or graphical windowing shell, is a
       specification for the graphical window system work surface (i.e.,
       the entire display screen).

       The desktop provides the user with a visual interface to available
       computer resources.  A desktop may be characterized as a visual
       analog of the POSIX shell.  It provides access to system resources,
       such as devices and files, and provides methods to start
       applications.  Desktops typically also provide a set of often used
       utilities such as a calendar, a notepad, etc.  The desktop is an
       important component of the look and feel of a graphical window
       system, but the current state of the industry is too immature for
       any standardization to materialize on a desktop specification in
       the immediate future.
       NOTE:  There are some valid arguments for defining some
       requirements for standards at this level.  The goal is to enable a
       user to easily go between application platforms and operate common
       functions in a similar manner.

























              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 148                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.8  Graphics Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _J_o_h_n _W_i_l_l_i_a_m_s


 4.8.1  Overview and Rationale

 Graphics Services are key components and play an important role in the
 POSIX Open System Environment as it is used today in many different areas
 of industry, business, government, education, entertainment, and most
 recently, the home.  The number of applications is growing rapidly, with
 increasing graphics capabilities.  Some of these areas are user
 interfaces, computer-aided drafting and design, electronic publishing,
 plotting, simulation, animation, scientific visualization, art, and
 process control.  The use of pictorial graphics provides a more intuitive
 interface and thus facilitates man/machine interaction.

 Graphics has become a routine part of most organizations today, ranging
 from hardcopy graphs and charts to user interfaces and complex 3-D
 visualizations incorporating video and sound.  The graphics technology of
 rendering objects has become dramatically more realistic and hence is
 used by engineers, architects, artists etc., to enable them to see
 precisely what their final products, whether automobiles or buildings,
 will look and behave like under real-world conditions.

 Graphics has allowed dramatic improvements in the ``look and feel'' of
 user interfaces and the trend is towards increasing use of these
 interfaces to interact with computers graphically, via windows and icons
 and this reduces the time involved in learning to use a computer.

 Standardization of graphics services has many benefits for application
 developers, users, and systems integrators.  The underlying motivations
 for considering graphics standards and their relation to the POSIX Open
 System Environment include:

     (1)  Portability:  In order to protect investment and achieve
          independence from a particular technology and a particular
          supplier of technology, portability at both hardware and
          software levels is necessary.  There are many aspects of
          portability within graphics, all of which are potential money
          and time savers.

           - Applications portability

           - Graphics package portability

           - Host machine independence




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 149






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

           - Device independence

              +o input devices:  dials, mouse, tablets etc.

              +o output devices:  plotters, raster, vector etc.

           - Window system independence

           - Programming language independence

           - Programmer portability

           - User portability

     (2)  Interoperability/Distributed Graphics:  In order to allow
          applications to execute on one machine and display graphics on
          remote display servers, standard graphics protocols are
          necessary.  This allows for display of graphics on machines that
          are incapable of executing particular types of applications and
          it also facilitates graphics conferencing.

     (3)  Graphics Data Exchange:  In order to share or exchange graphical
          information between diverse applications, standard graphics data
          exchange mechanisms are necessary.

 This clause presents a reference model for this component and describes
 the services provided to application programmers and users.  It also
 describes the current national/international standards, emerging
 standards, de facto standards, and any existing gaps that need new
 standardization efforts.


 4.8.2  Scope

 Included within this component are standards in the graphics area that
 address the following topics :

     - Application Program Interface (API) Standards

     - Language Bindings Standards

     - Metafile and Archive Standards

     - Device Independent Interface/Protocol Standards

     - Computer Graphics Reference Model

     - Conformance Testing of Implementations of Graphics Standards



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 150                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Distributed Graphics Standards

     - Imaging Standards

     - Performance Metrics Standards

 The standards not addressed here are:

     - Data Exchange Standards

     - Graphical User Interface Standards

     - Window Management System Standards


 4.8.3  Reference Model

 Over the past decade many computer graphics standards have been
 developed.  While they are similar in concepts, their underlying
 reference models are different.  This restricts the degree to which the
 standards are compatible.  By producing a reference model to which all
 future graphics standards are to adhere, compatibility of graphics
 standards is assured.

 Formal work on the Computer Graphics Reference Model (CGRM) standard is
 in progress within the ANSI X3H3.2 committee.  It is an international
 standard that explains the relationships between existing graphics
 standards and defines relationships between standards in computer
 graphics and those in other areas.  It will form the basis for the next
 generation of computer graphics standards.  Broadly speaking, CGRM
 provides a framework within which relationships between standards can be
 described.

 There are five types of standards in the current family:

     - _A_p_p_l_i_c_a_t_i_o_n _P_r_o_g_r_a_m _I_n_t_e_r_f_a_c_e (_A_P_I) _S_t_a_n_d_a_r_d_s:  These define a
       programming interface for application programmers.  GKS, GKS-3D,
       PHIGS, and Xlib are examples of standards in this area.

     - _M_e_t_a_f_i_l_e _a_n_d _A_r_c_h_i_v_e _S_t_a_n_d_a_r_d_s:  These standards define
       representations of graphics for storage and transfer between
       systems.  These are basically file format and file transfer
       encoding standards.  CGM (Computer Graphics Metafile) and PHIGS
       Archive files are of this type.

     - _D_e_v_i_c_e _I_n_d_e_p_e_n_d_e_n_t _I_n_t_e_r_f_a_c_e _S_t_a_n_d_a_r_d_s:  These standards define the
       interface between device-independent graphics systems software and
       one or more device-dependent graphics device drivers.  CGI
       (Computer Graphics Interface) is the standard in this area.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 151






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - _L_a_n_g_u_a_g_e _B_i_n_d_i_n_g _S_t_a_n_d_a_r_d_s:  API and device interface standards are
       functional specifications defined independently from particular
       programming languages.  Each standard has attached language binding
       standards that state how the functionality should be accessed from
       a variety of programming languages.

     - _F_r_a_m_e_w_o_r_k _S_t_a_n_d_a_r_d_s:  These include the standardization of a
       reference model for computer graphics, conformance criteria, and
       the registration of graphical items.

 The CGRM describes the current family of graphics standards in terms of
 the following four levels of abstraction:

     - _A_p_p_l_i_c_a_t_i_o_n _L_e_v_e_l:  This is the level at which applications-related
       information is composed into abstract graphics related to the
       application.

     - _V_i_r_t_u_a_l _L_e_v_e_l:  At this level, the graphical output to be displayed
       is described in terms of output primitives

     - _L_o_g_i_c_a_l _L_e_v_e_l:  At this level, the information necessary to render
       a primitive on a particular device is assembled.

     - _P_h_y_s_i_c_a_l _L_e_v_e_l:  This level is associated with a particular output
       device and a collection of input devices.  The physical level need
       not correspond to real devices such as a pen plotter.  There could
       be further layers of the system between the physical level and the
       hardware, such as the window system.

 The Application Program Interface (API) is the interface between the
 application and the graphics system.  There are also interfaces to
 metafiles and archives and to the operator.  Here the operator need not
 mean human operator, but the user of the graphics system; for example,
 the window system.

 The Computer Graphics Reference Model can be incorporated into the POSIX
 OSE reference model as depicted in Figure 4-17.  It provides the context
 for the discussion of graphics services and shows that the graphics
 services is a component of the overall POSIX OSE and is available to the
 the application through the POSIX OSE API.

 The entities and interfaces specific to the graphics services are
 identified in this clause.

 The entities are:

     (1)  Application Software, such as CAD/CAM/CAE applications, imaging
          applications, electronic publishing, etc.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 152                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________























 _________________________________________________________________________
     Figure 4-16  -  Computer Graphics Reference Model Level Structure


     (2)  Application Platform, which consists of graphics libraries such
          as GKS, PHIGS and Xlib.

     (3)  External Environment, consisting of external entities with which
          the application platform exchanges information such as input
          devices, X/PEX servers, hardware buffers, etc.

 The interfaces are:

     (1)  Application Program Interface (API), which is the programming
          interface between the application and the application platform.
          It standardizes the conceptual model, calling sequence,
          functions, and syntax that a programmer uses to develop a
          graphics application.  Each API standard has an attached
          language-binding standard that allows the functionality to be
          accessed from a variety of programming languages.  A standard
          API in conjunction with a standard language binding promotes
          application portability, by isolating the programmer from most
          hardware peculiarities and providing language features readily
          implemented on a broad range of processors.  Examples of APIs in
          the graphics services area are GKS, PHIGS, PIK, PostScript, etc.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 153






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________





























 _________________________________________________________________________
        Figure 4-17  -  POSIX OSE Graphics Service Reference Model


     (2)  External Environment Interface (EEI), which is the interface
          between the application platform and the External Environment
          described earlier.  In the graphics services area these can be
          device drivers that are used for communication between the
          device-independent and the device-dependent functions as well as
          protocols and file formats.

 The standardization efforts in the graphics area focus on these two
 interfaces.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 154                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.8.4  Service Requirements

 4.8.4.1  Graphics Concepts

 Computer Graphics Services can be discussed in terms of the following
 fundamental graphics concepts:

 _O_u_t_p_u_t__P_r_i_m_i_t_i_v_e_s

 The output primitives are the building blocks used to construct graphical
 objects for display or storage in an archive file.  Common output
 primitives are:

     - _L_i_n_e

     - _P_o_l_y_l_i_n_e used to represent a series of straight lines from a set of
       points.

     - _M_a_r_k_e_r is a special symbol used to represent semantics of graphical
       objects.

     - _F_i_l_l _a_r_e_a is an area with an edge and an interior which may be
       filled with a solid color or some form of pattern or hash.

     - _T_e_x_t is an output primitive used to represent strings in two or
       three dimensional space.

     - _A_n_n_o_t_a_t_i_o_n _t_e_x_t is text that is always displayed facing the viewer.

     - _C_e_l_l _a_r_r_a_y_s are areas with rectangular grids which can take on
       individual colors.

     - _T_r_i_a_n_g_l_e _s_t_r_i_p is a set of triangles defined by a particular
       ordering of vertices.

     - _Q_u_a_d_r_i_l_a_t_e_r_a_l _m_e_s_h is a set of quadrilaterals defined by a grid of
       vertices.

     - _S_u_r_f_a_c_e_s:  NURBS (Nonuniform Rational B-Spline)

     - _C_u_r_v_e_s:  NURBS (Nonuniform Rational B-Spline)

     - _C_o_n_i_c_s:  Circles, ellipses, parabolas, and hyperbolas

 _P_r_i_m_i_t_i_v_e__A_t_t_r_i_b_u_t_e_s

 Attributes of primitives determine the style of the display of the
 primitive.  For example, lines and edges may have different line styles
 such as dotted or dashed, text may have different fonts, orientation, and


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 155






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 character spacing.  A polymarker may be an asterisk or a small triangle.
 They all may be red in color.  General type attributes that apply to
 almost any output primitive are color, visibility, pickability, and
 highlight method.

 _I_n_p_u_t__P_r_i_m_i_t_i_v_e_s

 Input primitives or logical devices are virtual devices designed to
 insulate the application from the real input devices.  Logical devices
 include picking devices, locator devices, choice devices, valuator
 devices, etc.  In terms, of actual devices, a locator device might be
 associated with the first mouse button.

 _I_n_p_u_t__M_o_d_e_l

 The input model describes how input primitives and logical devices are
 related to physical input devices and the degree of control provided to
 the application over the devices.  For example, one control choice might
 be how feedback is echoed to the operator when a logical locator device
 is attached to a depressed mouse button.  The feedback might be a
 rectangular cursor or the highlighting of geometry as a cross-hair cursor
 moves over it.  When the button is released the device coordinates are
 placed in the locator data record and an event is placed in an event
 queue for which the application can check asynchronously.  The method the
 application uses to determine if a device has data for it is usually
 described in terms of modes.  A common mode is event mode.  The
 application waits a finite time for some event to appear in a queue.  If
 no event comes in the finite time, the application does other processing
 and eventually comes back to check the queue with the wait for some
 event.  If an event appears, the application determines what type it is
 and gets the data for that type of event.  For a pick device, the data
 might be all possible graphical primitives that could intersect some
 aperture, possibly specified in the device coordinate system.

 _C_o_o_r_d_i_n_a_t_e__S_y_s_t_e_m_s__a_n_d__C_l_i_p_p_i_n_g

 Part of the graphics services is a means to utilize various coordinate
 systems.  Graphical output has to be described to the graphics system in
 terms of some coordinate system, relevant to the application and
 presented to the display device in terms of its own coordinate system,
 the device coordinate system.  It is unlikely that these two coordinate
 systems will be the same.  A graphics system may therefore involve a
 number of coordinate systems and hence the need to define transformations
 between them.  Some standard types of transformations are scaling,
 rotating, translating, reflecting, and projection, such as parallel and
 perspective.  They are used to manipulate objects in a coordinate system
 and to map from one coordinate system to another.  The coordinate systems
 commonly used are modeling coordinates, world coordinates, view-reference
 coordinates, normalized projection coordinates, and device coordinates.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 156                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 Clipping is the process of specifying a region in space and restricting
 graphical output to that region.  Only those primitives that define
 objects in that region will have their output displayed.

 _O_u_t_p_u_t__M_o_d_e_l

 The output model is the concept of how graphics objects are created,
 displayed, and controlled on output devices.  The output model defines
 how to position and organize objects on the screen, and the visual state
 of these objects such as visible or invisible, hidden lines removed or
 not removed, picture matches retained structure, picture not consistent
 with retained structure, etc.

 More specifically, the output model concept is made up of the:

     - Transformation pipeline

     - Rendering pipeline

     - Retained structures

     - Nonretained structures

     - Graphics state

     - Window systems

                                                                            e

 _S_t_o_r_a_g_e_/_A_r_c_h_i_v_i_n_g

 Storage data formats for displayed or rendered images are required, but    e
 not treated at this time.                                                  e

 4.8.4.2  Graphics Requirements

 The graphics service requirements of all users of this system can be
 generalized as:

     - The ability to create, delete, and modify output primitives.

     - The ability to specify and edit the primitive attributes globally
       and individually.

     - The ability to transform (i.e., scale, translate, rotate, reflect,
       project, etc.) primitives for construction of more complex objects
       and for arrangement in the viewing space.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 157






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - The ability to create and manipulate a database of primitives, to
       define and edit attributes, to create and combine transformations,
       and to selectively control the display of graphics primitives.

     - The ability to display graphical objects constructed in a retained
       database, or the ability to display primitives immediately, or to
       display from both a retained database and immediately.

     - The ability to apply lighting and shading algorithms to collections
       of graphical objects with multiple light types and sources.

     - The ability to prepare display data and control the timing of the
       actual display of the display data.  On some systems this is
       referred to as frame buffer control.

     - The ability to store and retrieve graphical objects from files.

     - The ability to control input devices and retrieve data from input
       devices.

     - The ability to direct output to a meta-file and retrieve graphics
       data from a meta-file.

     - The ability to inquire about all aspects of the graphics
       environment; e.g., the state of the system at any given time, the
       actual capabilities of a given hardware platform, the attributes
       and primitives supported by a given implementation, etc.

     - The ability to distribute graphics.

     - The ability to control errors.

 4.8.4.3  Application Program Interface Services

 The major categories of graphics services available in the POSIX OSE API
 area include:

     - 2-D graphics API services

     - 3-D graphics API services

     - Device interface API services

     - Image processing API services

 For most of these API standards there exist standard language bindings so
 that applications using different programming languages can access the
 same functionality.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 158                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 The choice of which graphics standard API to use will depend on a number
 of factors:  application profile, overall system architecture, equipment
 available, existing application database interaction, system performance
 considerations, user interface requirements, management policy, and other
 external factors.  The aim of producing a compatible set of graphics
 standards in GKS, GKS-3D, PHIGS, PHIGS PLUS, etc.  (described in the
 Standards subclause) is to allow that choice to be made in the most
 flexible way.

 4.8.4.4  External Environment Interface Services

 The major categories of graphics services in the POSIX OSE EEI area
 include:

     - Protocols

     - File Formats

     - Device Drivers

 The choice of which standard to use depends on a number of factors:
 application profile, system architecture, equipment available, system
 performance considerations, and other factors

                                                                            e


 4.8.5  Standards, Specifications, and Gaps

 There are several major standards existing in the computer graphics
 industry today, that have been approved by National/International
 organizations such as ANSI, ISO, and IEEE.  There are also standards
 efforts going on in related areas such as application data exchange.
 These official graphics standards are complemented by de facto standards
 that have been accepted by the graphics industry at large.  This document
 provides a general explanation of these standards, their specifications,
 and interrelationships.

 4.8.5.1  Current Standards

    PHIGS -- ISO 9592 Parts 1-3
    Fortran Language Binding -- ISO 9593-1
    Ada Language Binding -- ISO 9593-3
    C Language Binding -- DIS 9593-4

          The Programmer's Hierarchical Interactive Graphics Standard
          (PHIGS) is a functional specification of the interface between
          an application program and its graphics support system.  It is
          an ANSI/ISO standard and provides the following graphics


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 159






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________





























 _________________________________________________________________________
   Figure 4-18  -  POSIX OSE Graphics Service Reference Model Standards


          functionality:

           - A high degree of interactivity

           - Multilevel, hierarchical structuring of graphics data

           - Easy modification of graphics data and the relationships
             among the data

           - 3-D, as well as 2-D, graphical input and output

           - Offline storage (and retrieval) of graphics data

          PHIGS controls the definition, modification, and display of
          hierarchical graphics data and specifies functional descriptions


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 160                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


                     Table 4-10  -  Graphics Standards                      e
 __________________________________________________________________________________________________________________________________________________  e
                 Service                   Type       Specification        Subclausee
 ___________________________________________________________________________________e

 PHIGS                                      S     ISO 9592-1, -2, -3       4.8.5.1  e       ee
 PHIGS PLUS                                 E     ISO DIS 9592-4           4.8.5.2  e       ee
 GKS                                        S     ISO 7942                 4.8.5.1  e       ee
 GKS-3D                                     S     ISO 8805                 4.8.5.1  e       ee
 CGI                                        E     ISO DIS 9636             4.8.5.2  e       ee
 CGM                                        S     ISO 8632-1, -2, -3, -4   4.8.5.1  e       ee
 PHIGS Archive files                        S     ISO 9592-2, -3           4.8.5.1  e       ee
 IPI                                        E     JTC 1 N1002              4.8.5.2  e       ee
 Conformance Testing                        E     ISO DIS 10641            4.8.5.2  e       ee
 PEX                                        G     MIT Consortium           4.8.5.3  e       ee
 Graphics Style Guide                       G     -                        4.8.5.3  e       ee
 Control and Deterministic Functionality    G     -                        4.8.5.3  e       ee
 CGRM and Windows                           G     -                        4.8.5.3  e       ee
 Solids                                     G     -                        4.8.5.3  e       ee
 Cut and Paste                              G     -                        4.8.5.3  e       ee
 Nonretained Graphics                       G     -                        4.8.5.3  e       ee
 __________________________________________________________________________________________________________________________________________________  e


          of systems capabilities, including the definition of internal
          data structures, editing capabilities, display operations, and
          device control functions.  PHIGS manages the organization and
          display of data in a centralized database, allowing programmers
          to define and organize graphical data in a manner most
          convenient to the application.  Such a hierarchical approach is
          a big benefit and is not available in GKS, another international
          standard.

          Objects are defined in the PHIGS graphical database by a
          sequence of elements, including output primitives, attributes,
          transformations, and invocations of other object and object part
          definitions.  These elements are grouped into entities called
          structures.  Structures may be related in a number of ways,
          including geometrically, hierarchically, or according to
          inherent properties or characteristics, as defined by an
          application.

          PHIGS provides tools to use hierarchical data structures with
          minimal effort by the application programmer.  Pictures
          constructed from geometric models often have a clearly evident
          structure.  This structure can sometimes be easily seen in the
          repeated use of symbols, in the connections and geometric
          relationships between objects, or in the overall organization of


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 161






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS


            Table 4-11  -  Graphics Standards Language Bindings             e
 __________________________________________________________________________________________________________________________________________________  e
 Standard         LIS       Ada        APL       BASIC        C        C++  e
 _________________________________________________________________________  e

 PHIGS                       S                                E             e
 GKS                         E                                E             e
 GKS-3D                      E                                E             e
 CGI                                                          E             e

 Standard      COBOL     C-LISP     Fortran     Pascal     PL/1     Prolog  e
 _________________________________________________________________________  e

 PHIGS                                 S                                    e
 GKS                                   S          S                         e
 GKS-3D                                E          E                         e
 CGI                                   E                                    e
 __________________________________________________________________________________________________________________________________________________  e
 NOTES:  LIS -- Language-independent specification is available.            e

 Ada, APL, BASIC, -- Language-dependent specifications exist.               e

 S, E, G -- Standard, Emerging Standard, Gap                                e


          a complex image.  Even if the object's structure is not evident,
          its underlying data organization may be quite rigorous, well
          defined, and well understood by the application.  PHIGS supports
          both these cases by separating the definition of graphics data
          from the actions required to display them.

          The structured definition of graphics data inherently reduces
          repetition and connectivity problems.  The repeated use of
          component objects and the relationships between them can
          automatically be made a part of an object's definition.

          The structured definition of data allows images to share
          component objects, making it faster and easier for application
          programs to define and modify picture descriptions.  Sharing
          component objects will also reduce storage requirements for
          graphics data.

          PHIGS permits rapid dynamic access to a centralized graphics
          database.  This allows PHIGS to support interactive end user
          application programs and, depending on the capability of the
          hardware, realtime definition, and modification of graphics
          data.  PHIGS is capable of performing three-dimensional modeling
          transformations, workstation transformations, and viewing.  It


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 162                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          also handles two dimensions through a shorthand functionality of
          three dimensions.  In workstation transformations, PHIGS
          provides another level of display control after the viewing
          operation that can isolate a section of an image for pan and
          zoom operations.

          The National Institute of Standards and Technology (NIST) has
          developed a test system to help determine whether
          implementations of PHIGS conform to the specifications of the
          ANSI standard X3.144.  The PHIGS Validation Test (PVT) suite
          consists of highly portable Fortran programs which examine test
          conditions and report the results.

    PHIGS PLUS -- DIS 9592-4

          PHIGS Plus Lumiere Und Surfaces (PLUS) specifies a set of
          extensions to PHIGS that addresses some of the deficiencies in
          the graphics functionality provided by PHIGS.  PHIGS does not
          include ``higher level'' primitives such as curves and surfaces,
          and techniques for lighting and shading.  Recognizing this, an
          ad hoc working group was formed to propose a set of extensions
          to PHIGS to enable these capabilities to be addressed in a
          standard manner, compatible with the overall philosophy of
          PHIGS.  This set of proposed extensions was submitted to ISO and
          has since been developed into PHIGS PLUS.  PHIGS PLUS enhances
          PHIGS by providing:

           - Primitives for defining curves and surfaces

           - Lighting models

           - Shading of surfaces

           - Depth cueing

           - Color mapping and direct color specification

          PHIGS PLUS is not an international standard yet and is currently
          at the stage of committee draft.

    GKS -- ISO 7942; FIPS 120
    Fortran Language Bindings -- ISO 8651-1
    Pascal Language Bindings -- ISO 8651-2
    Ada Language Bindings -- DIS 8651-3
    C Language Bindings -- DIS 8651-4

          GKS Information Bulletin




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 163






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          The Graphical Kernel System (GKS) is a 2-D graphics system and
          provides no support for 3-D.  It is a 2-D graphics API that
          shields the programmer from differences among various computers
          and graphic devices.  It allows for portability of graphics
          applications by standardizing the basic graphic functions and
          the method and syntax for accessing these functions.

          GKS is an ANSI, ISO standard and is widely used today.  It has
          standard language bindings for Fortran and Pascal.  Language
          bindings for C, Ada, and LISP are currently being worked on.

          GKS supports the grouping of logically related primitives such
          as lines, polygons, strings, and their attributes into
          collections called segments, which cannot be nested.

          GKS supports many graphical input and output devices such as
          black/white and color displays, printers, plotters, mice, data
          tablets, joysticks, and digitizers.

    GKS-3D -- ISO 8805
    Fortran Language Bindings -- DIS 8806-1
    Pascal Language Bindings -- CD 8806-2
    Ada Language Bindings -- DIS 8806-3
    C Language Bindings -- DIS 8806-4

          Graphical Kernel System for Three Dimensions (GKS-3D) is an ISO
          standard and specifies extensions to GKS for defining and
          viewing three-dimensional wire-frame objects.  In addition, the
          GKS input model has been extended to provide three-dimensional
          locator and stroke input.  GKS-3D allows the operator to obtain
          information from three-dimensional input devices and to perform
          hidden line/hidden surface removal (HLHSR) at the workstation.
          It does not, however, provide specific functions for controlling
          rendering techniques such as light source, shading, texturing,
          and shadow computations that must be done locally at the
          workstation.  Conceptually, all workstations are three-
          dimensional in GKS-3D, which is made possible by shielding the
          hardware peculiarities as in GKS.

    CGI -- DIS 9636 Parts 1-6
    Fortran Language Bindings -- DIS 9638-1
    C Language Bindings -- CD 9638-4

          The Computer Graphics Interface (CGI) specifies a standard
          functional and syntactical specification of the control and data
          exchange between device-independent graphics software and one or
          more device-dependent graphics device drivers.  Unlike the
          graphics standards discussed earlier, CGI specifies an interface
          at the device-driver level, rather than at the application


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 164                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          level.

          Unlike CGM, which only handles graphical output, CGI handles
          both input and output, which makes all devices appear as
          identical, virtual graphics devices.  Therefore, this protocol
          is also known as the Virtual Device Interface (VDI).  It
          provides a standard graphics escape mechanism to access
          nonstandard graphics device capabilities.  CGI allows
          programmers to write portable device-driver software that is
          independent of the physical graphics device characteristics.
          This makes the software portable and compatible with a wide
          variety of devices.

    CGM -- ISO 8632 Parts 1-4

          The Computer Graphics Metafile for storage and transfer of
          picture description information (CGM) is a mechanism for
          retaining and/or transporting graphics data and control
          information.  This information contains a device-independent
          description of a picture at the level of the Computer Graphics
          Virtual Device Interface described above.  It provides a
          standard graphics escape mechanism to access nonstandard
          graphics device capabilities via the metafile.

          Pictures are described in CGM as a collection of elements of
          different kinds, representing, for example, primitives,
          attributes, and control information.  It is multipart ANSI, ISO
          standard.  Part 1 contains the semantics of all the elements.
          Parts 2, 3, and 4 contain the syntax of three different bindings
          of the standard, namely:  character-coded, binary, and clear-
          text encodings.

    PHIGS Archive files -- ISO 9592 Parts 2-3

          Parts 2 and 3 of the PHIGS standard define an archive file
          format for storage and transfer of PHIGS structures and
          structure network definitions from the CSS (Central Structure
          Store).  Part 2 describes the file format and Part 3 a clear
          text encoding.  This encoding is constructed using the same
          techniques as used by CGM.

 4.8.5.2  Emerging Standards

    IPI -- JTC 1# 1002

          Image Processing and Interchange is a functional specification
          and several language bindings for an Application Programmer
          Interface to Imaging.  The standard defines the data objects,
          primitive operations, and a reference model.  The API supplies


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 165






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          the basic building blocks upon which applications requiring
          imaging functionality can be built within conventional,
          distributed, and image oriented computing environments.

          The International Standard for Image Processing and Interchange
          includes three parts:

             Part 1   Common Imaging Architecture

             Part 2   Programmer's Imaging Kernel (PIK)

             Part 3   Image Interchange Format

    Conformance Testing of Implementations of Graphics Standards -- DIS
          10641

          The existence of any standard brings up the question of how one
          can be sure whether a product claiming to conform to the
          standard does in fact conform.  If this question is not
          addressed then the process of standardization becomes pointless.

          The general approach to software validation is through testing.
          The method is to subject the software to a collection of test
          cases and observe the results.  If the results are different
          from what is expected, the software does not conform to the
          specification.  The ANSI X3H3.7 committee is working on a
          standard that specifies the characteristics of standardized test
          sets for use in determining the conformance of implementations
          of graphics standards.  It will also provide guidance to
          functional standards developers concerning the content of their
          standards and the conformance rules within standards.

 4.8.5.3  Gaps in Available Standards

 4.8.5.3.1  Public Specifications                                           e

    PEX -- PHIGS Extensions to X                                            e

          PEX is a network protocol extension to the X Window System.  As   e
          many applications require 3-D graphics and other forms of input   e
          devices such as dials and button boxes, all of which are not      e
          supported by X, it became necessary to extend the X Protocol to   e
          include 3-D graphics.  PHIGS was selected as the application      e
          program interface because of its acceptance as a 3-D standard,    e
          its high degree of input ability, and its powerful database       e
          editing capabilities.  In 1988, the MIT X Consortium contracted   e
          to add 3-D and extended input extensions to the X protocol and    e
          the first release of PEX as a sample implementation (PEX-SI) was  e
          made in January 1991 but is not yet available commercially.       e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 166                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          Using PEX, PHIGS workstations would be defined as X Windows.      e
          For the programmer, X, PHIGS, and PEX standards provide           e
          portability.                                                      e

 4.8.5.3.2  Unsatisfied Service Requirements                                e

     - Applications have different behaviors for similar functions which
       hinders user portability.  By adopting a uniform approach
       (Graphics_Style_Guide) users can switch between applications
       without a lot of training.

     - Current existing standards allow a wide interpretation for
       implementors of the standards thus denying the applications useful
       controls.  In order to achieve true portability in a distributed
       environment, applications will need control and deterministic
       functionality.

     - How window standard fits into CGRM

     - Current existing standards do not address solids.

     - The ability in a standard defined way to perform cut and paste
       between applications.

     - Current standards do not allow nonretained graphic methods to do
       lighting and shading.


 4.8.6  OSE Cross-Category Services

 Not applicable.


 4.8.7  Related Standards

    IGES, NBSIR 86-3359

          See 4.5.

    X Window System Data Stream Definition Parts 1-4

          (Being worked on in ANSI X3H3.6)

    Part 1: Functional specification
    Part 2: Data Stream Encoding
    Part 3: KEYSYM Encoding
    Part 4: Mapping onto Open Systems Interconnection (OSI) Services




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 167






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

          The X Window System is a network based windowing and 2-D
          graphics system.  It uses the client-server model.  The client
          and server can reside on the same or different platforms.  The
          client is an application program executing anywhere on the
          network and displaying on the screen.  It does this by making
          calls to a library called Xlib to generate protocols.  The X
          server is the software that accepts protocols sent by the client
          and processes them for display.  It also accepts input from a
          mouse or keyboard for return to the application program.  The X
          protocol specifies the data stream encoding between the server
          and the clients.  The X Protocol originally developed by the X
          Consortium at MIT, is being standardized by the ANSI X3H3.6
          committee.  The encoding will provide a standard interface for
          applications running on both distributed and nondistributed
          environments having high-speed, reliable, network based
          communications.

          X Protocol is designed to work in a heterogeneous network
          environment.  Below the X Protocol, any lower layer of network
          can be used, as long as it is bidirectional.  Currently TCP/IP
          and DECnet are the two network protocols commonly supported in X
          servers.  Part 4 of this standard specifies the mapping of X
          Windows onto the OSI Services.

    XLIB

          Xlib--C Language X Interface is the common component of X
          Windows and resides on all X-based systems.  Although X is
          fundamentally defined by a network protocol, application
          programmers do not interface directly with the X Protocol.
          Instead, they interface to the X Protocol through Xlib.

          The X Window System uses the client-server model.  The client is
          an application program executing anywhere on the network and
          displaying on the screen.  It does this by making calls to Xlib
          to generate protocols.  The X server is the software that
          accepts protocols sent by the client and processes them for
          display.

          From a graphics perspective, Xlib is a 2-D graphics library and
          provides graphics primitives like points, lines, and arcs.  It
          has a Graphics Context (GC) to allow modification of graphics
          attributes such as line type, line width, color, and font type.
          The Xlib developed initially at MIT is in the Public Domain and
          is a de facto standard for windowing and 2-D graphics.  It has
          been adopted by major computer vendors and industry groups.  It
          is currently being considered for standardization by the IEEE
          P1201 committee.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 168                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

    PostScript

          The PostScript language from Adobe Systems Incorporated is a
          simple interpretative programming language with powerful
          graphics capabilities that has become a de facto industry
          standard.  It is a high-level, device independent language that
          is primarily used to describe the appearance of text, graphical
          shapes, and images on printed pages or screens.  Programs
          written in this language may be used to communicate information
          from a composition system to a printing system.  PostScript
          programs are created, transmitted, and interpreted in the form
          of source text and there is no compiled or encoded form of this
          language.

    SGML, ISO 8879: 1986

          See 4.5.

    IGES/PDES Organization (IPO)

          See 4.5.

    ISO/IEC TC184/SC4 (STEP)

          See 4.5.

    ISO/IEC TC130 (Color Prepress)

    ISO/IEC JTC 1/SC18 (Text and Office Systems

    ISO/IEC JTC 1/SC29 (Multimedia Coding)

                                                                            e


















              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.8 Graphics Services                                                 169






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS




















































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 170                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.9  Character-Based User Interface Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _M_a_r_t_i_a_l _V_a_n _N_e_s_t_e                                         _e


 4.9.1  Overview and Rationale

 This clause describes the system services that are related to character-
 based terminals.  It describes both the application program interfaces to
 character-based terminals and also the look and feel of the interaction
 between the user and the user interface equipment.

 Despite the attention paid to graphical window interfaces, the vast        e
 majority of applications are written with a character based user           e
 interface.  In fact, character-based devices are best suited for           e
 applications where the constraints of cost, speed, and the clutter of a    e
 pointing device on the desk are a major concern.                           e

 It should be noted also that there are character-based window              e
 applications that may not have all the flexibility and ease of use of      e
 their graphic counterparts, but represent an alternative allowing the      e
 utilization of the large installed base of character terminals and still   e
 improve the ease of use.                                                   e

 This clause is one portion of the User Interface API and EEI as described
 in Section 3.


 4.9.2  Scope

 The scope of this clause is limited to the services and standards
 required to support character (non-bitmapped) terminals.  The services     e
 described here do not preclude the use of block-mode terminals, even       e
 though most applications built on POSIX-compliant platforms historically   e
 have used character-stream terminals.                                      e


 4.9.3  Reference Model

 This subclause identifies the entities and interfaces specific to the
 character-based terminal services of an OSE.

 As illustrated in Figure 4-19, the components of character-based
 interfaces are broken into two groups:  those specifications that impact
 the application programming interface and those that impact the external
 user interface.

 This reference model is consistent with and expands on the reference
 model in Section 3.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.9 Character-Based User Interface Services                           171






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________























 _________________________________________________________________________
         Figure 4-19  -  Character-based Terminal Reference Model


 4.9.4  Service Requirements

 The fundamental service requirements for character-based terminals are to
 allow applications to be written that make use of the features of a wide
 variety of terminals using a single terminal-independent interface.  The
 look and feel of user interactions should be consistent between            e
 applications to make moving between applications as simple as possible.

 4.9.4.1  Application Program Interface Services

 Application services include those made available to the application       e
 developer to separate the application function from the user interface     e
 functions as much as possible.                                             e

 These standard services support requirements for application portability   e
 and terminal independence.                                                 e

 _P_r_e_s_e_n_t_a_t_i_o_n__M_a_n_a_g_e_m_e_n_t                                                    e

 Functions available for Presentation Management are:                       e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 172                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Placement of text on the screen using a consistent reference         e

     - Positioning of the cursor for further output on the scree or for     e
       user input                                                           e

     - Control of attributes of displayed text such as highlighting,        e
       underscoring, and coloring, if available                             e

     - Clearing or refreshing the screen                                    e

     - Getting the current cursor position                                  e

 _S_c_r_e_e_n__M_a_n_a_g_e_m_e_n_t                                                          e

 Functions available for Screen Management are:                             e

     - Control of the number and the width of the lines displayed           e

     - Use of a protected status line                                       e

     - Protection from writing or clearing in defined portions of the       e
       screen                                                               e

     - Auto-wrapping in defined portions of the screen                      e

 _I_n_p_u_t__D_e_v_i_c_e__M_a_n_a_g_e_m_e_n_t                                                    e

 Functions available for Input Device Management are:                       e

     - Configuration of the function keys, if available                     e

     - Keyboard locking                                                     e

     - Changing key mappings                                                e

 _F_o_r_m__M_a_n_a_g_e_m_e_n_t                                                            e

 Functions available for Form Management are:                               e

     - Definition of a form with different output and input text fields     e

     - Definition of the attribute input fields, such as text or different  e
       numeric formats                                                      e

     - Generic and customizable error handling procedures for incorrect     e
       input                                                                e





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.9 Character-Based User Interface Services                           173






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.9.4.2  External Environment Interface Services

 The look and feel of user interactions with applications should be
 standardized to make moving between applications as simple as possible.
 The areas that require standardization are:
                                                                            e

     - Style of selecting commands                                          e

     - Accessing online help                                                e

     - Performing common functions such as page forward and page            e
       backwards.                                                           e

     - Selecting or moving between fields in a forms-based environment      e

 These interactions will differ slightly between different types of
 terminals because of limitations of the terminals.

 4.9.4.3  Related Service Requirements

 To be provided.


 4.9.5  Standards, Specifications, and Gaps

 4.9.5.1  Current Standards

 None.

 4.9.5.2  Emerging Standards

 _F_I_M_S

 ANSI CODASYL.  A working draft is available for Forms Interface
 Management System (FIMS), which covers the interface between a
 programming language and any form-filling application on a computer or
 terminal screen.

 This specification addresses some of the services requirements for a
 forms-based user interface.

 4.9.5.3  Gaps in Available Standards








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 174                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.9.5.3.1  Public Specifications

                                                                            e

 _C_u_r_s_e_s

 Curses is a set of subroutines that provide a terminal-independent
 interface to applications.  Many different types of character-based
 terminals are supported.  Curses lacks complete support for flexible user
 input.

 This specification satisfies some of the service requirements for          e
 character mode terminals.  A recent specification for Curses can be found  e
 in volume 3 of X/Open's XPG3.                                              e


 4.9.6  OSE Cross-Category Services

 4.9.6.1  Security

 _T_o _B_e _P_r_o_v_i_d_e_d.                                                            e

 4.9.6.2  Administration

 It is important to allow the system management personnel to configure the
 system to designate where each terminal is connected.  Also needed is the
 ability to add support for new terminals without affecting the
 application interface.

 4.9.6.3  Configuration Management

 The system could include a descriptive database of a current set of        e
 supported terminals, so that terminal-independent services can do the      e
 mapping for the different functions.                                       e


 4.9.7  Related Standards

 None.












              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.9 Character-Based User Interface Services                           175






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS




















































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 176                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.10  User Command Interface Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _W_e_n_d_y _R_a_u_c_h


 4.10.1  Rationale and Overview

 Although system-level services are necessary for application portability
 and interoperability, they are insufficient for many users' system needs.
 To maximize portability, users also require the commands, command
 interpreter (shell), compilers, editors, and other utilities that have
 been traditionally associated with many operating systems.  These command
 interface services facilitate a successful port and help users to manage
 and maintain applications and to solve problems on an ad hoc basis.  The
 standardization of these utilities allows users and programmers to move
 from platform to platform without having to relearn the command interface
 for each application platform.


 4.10.2  Scope

 This clause describes how a user interacts with an application platform
 by executing general purpose commands.  This command interface is also
 available to applications so that applications also can execute commands.
 A standardized command interface provides a consistent, interactive
 environment across platforms for users and programmers.

 Commands that are outside the scope of this clause are:

     - System administration and installation commands

     - Text formatting programs

     - Database commands

     - Networking and communications commands

     - Graphical user interfaces

 Networking commands and graphical user interfaces are described in other
 clauses of this guide.


 4.10.3  Reference Model

 The use of the command interface services presented in this clause is
 consistent with the reference model in Section 3.  The POSIX OSE
 reference model for the command interface also is consistent with typical
 implementations for user command languages in traditional UNIX-based


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.10 User Command Interface Services                                  177






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________
















 _________________________________________________________________________
     Figure 4-20  -  POSIX OSE Reference Model for Command Interfaces


 systems.

 As Figure 4-20 shows, the command interface is available both to users
 (through the External Environment Interface) and to applications (through
 the Application Programming Interface).  Any operating system
 implementation can reside underneath the APIs and EEIs.

 The API and EEI command interfaces provide access to a software component
 (known as a command interpreter or shell) that interprets the commands
 issued by either the user or the application.  The command interpreter
 acts as an intermediary between the command API and EEI and the base
 application platform's system-level services.  The command interpreter
 reads the commands entered and parses them.  Depending on the type of
 command (e.g., utility or built-in shell command), the command
 interpreter either executes the command for the user or application,
 using the base application platform's system-level services, or it calls
 on the system-level services to create a new process which executes the
 command.

 None of the methods of executing commands have an impact on the API or
 EEI specifications.

 The commands interfaces may be available to users and applications either
 locally or remotely.  Remote invocation of a system's command interfaces
 is provided through networking and data interchange capabilities.  These
 are described in 4.3 and 4.5.  Alternatively, remote access to a system's
 command interfaces may be available through certain interapplication
 services.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 178                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 4.10.4  Service Requirements

 There are three major aspects of command interface services that must be
 addressed for practical support of multivendor application portability
 and system interoperability.  The first aspect consists of the basic
 functionality and interfaces provided for generally usefulness.  The
 second aspect of command interface services concerns the ability to move
 applications, such as script files, between platforms.  The third aspect
 concerns user portability so that the same user interface is available on
 different platforms.

 Since most command interfaces are available at the API and EEI, the
 service requirements for the API and the EEI are very similar.  This
 clause, therefore, discusses primarily the EEI command interface
 requirements.  The API service subclause discusses only the additional
 service requirements for applications.

 4.10.4.1  Application Program Interface Services

 In a command API, the output syntax of the commands and command responses
 (such as error messages) need to be standardized, in addition to the
 calling sequence and allowable inputs.  Such standardization is necessary
 to allow applications executing a command to reliably parse the output of
 that command.

 The API should be able to access all of the services available to the
 user at the EEI.  The additional service requirements for the API are as
 follows:

     - Ability to provide the input to the command and access the output
       of the command when necessary

     - Ability for the application to detect and correct errors as the
       command is executed

     - Ability to abort or suspend the command as it is executing.

 It is also important to have the ability to create script files which are
 combinations of commands.  The scripting language developed for this
 purpose is an application development language.  The scripting language
 has the following requirements:

     - Conditional execution primitives

     - Repeated execution primitives

     - Ability to display output




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.10 User Command Interface Services                                  179






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Ability to prompt the user for input

     - Ability to execute commands and obtain error information.

 The services and standards for the scripting language are described in
 this clause, rather than in the Languages clause 4.1, because it is so
 closely related to the command interface.

 4.10.4.2  External Environment Interface Services

 Users need a number of capabilities in order to work on a system.  On a
 traditional system, these are implemented by providing interactive
 commands entered via a keyboard.  However, as graphical user interfaces
 evolve, these commands may also be implemented by clicking on a mouse in
 a particular area of the screen, by a touch screen, a tablet, or other     e
 input device.                                                              e

 The major services at the EEI provide the following abilities:

     - Capture the output of a command or application into a file

     - Redirect the input for a command from a file

     - Direct the output of a command to be used as the input to another
       command

     - Execute applications

     - Get online help for commands or applications

     - Manipulate file contents:

        +o Cutting

        +o Pasting

        +o Concatenating

        +o Converting

        +o Sorting

        +o Reformatting

        +o Comparing

        +o Searching for regular expression




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 180                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Edit files

        +o Interactive editors

        +o Batch or ``stream'' editors

     - Display files

        +o Pausing when necessary

        +o Display only selected ranges of files

     - Manipulate files

        +o Create

        +o Delete

        +o Rename

        +o Move

        +o Copy

     - Print files

     - Perform network functions

        +o File transfer

        +o Remote execution of commands

        +o Remote file printing

     - Perform batch processing                                             e

        +o Create and manage batch queues                                    e

        +o Submit, terminate, and get status of jobs                         e

        +o Retrieve output                                                   e

     - Manipulate and display directories

        +o Create

        +o Delete




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.10 User Command Interface Services                                  181






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

        +o Display

        +o Destroy (Delete a directory and all its subdirectories and
          files)

     - Control file and directory permissions

     - Communicate with other users

        +o Electronic mail

        +o Online interaction where two or more users communicate with each
          other simultaneously

     - Control the application execution environment

        +o Execute applications in the background

        +o Abort applications running in the foreground or background

        +o Suspend an application

        +o Move an application running in foreground mode to the background

     - Schedule commands for periodic execution

     - Control the users' input equipment, such as a terminal or graphical
       user interface

     - Manage local environment and configuration information

     - Query local environment and configuration data

     - Configure an environment for an international locale.

                                                                            e
 These services enable remote users and applications to access and execute
 a system's command interfaces as if they were directly connected to that
 system.  The major categories of interapplication entity services include
 the following:

     - Login and use hosts on a network as if the users logging-in were
       directly connected to the local terminal

     - Remotely execute a system's shell commands as if the user were
       directly connected to a local terminal

     - Copy files between hosts without going through a network file
       transfer program


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 182                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Find out who else is logged into the machines on a local-area
       network

     - Query the status and uptime of all machines on a local-area
       network.


 4.10.5  Standards, Specifications, and Gaps

 There are currently no formal standards for command interfaces.  There
 are, however, several command-interface standards-development activities
 underway.  In addition, there are several consortia-defined
 specifications and de facto specification standards for commands, shell,
 and utilities services and interfaces.

 Table 4-12 summarizes the shell and utilities standards and
 specifications and work in progress.


               Table 4-12  -  Shell and Utilities Standards
 __________________________________________________________________________________________________________________________________________________
              Service                Type     Specification     Subclause
  _______________________________________________________________________

  Shell and Utilities                 E     IEEE POSIX.2        4.10.5.2    ee

  User Portability Extension (UPE)    E     IEEE POSIX.2a       4.10.5.2    ee

  Control of interprocess             E     IEEE POSIX.4        4.10.5.2    eee
  communications, shared memory,                                            e
  and semaphores                                                            e

  File transfer utilities, remote     G     X/Open XPG3,        4.10.5.3    eeee
  command execution, remote file            OSF OSF/1,                      ee
  printing, electronic mail,                SVID,                           ee
  operating-system-based software           Berkeley BSD 4.x                ee
  development aids                          UNIX                            ee
 __________________________________________________________________________________________________________________________________________________


 4.10.5.1  Current Standards

                                                                            e
 There are no currently completed or approved international or national
 standards for commands and utilities.






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.10 User Command Interface Services                                  183






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 4.10.5.2  Emerging Standards

 _I_E_E_E__P_O_S_I_X_._2                                                               e

 When completed, the IEEE POSIX.2 standard will define a source code
 interface to command interpretation or shell services and common utility
 programs for application programs.  These services and programs are
 complementary to those specified by POSIX.1 {2}.

 The IEEE POSIX.2a User Portability Extension will supplement POSIX.2 by
 extending the specifications to promote the portability of users and
 programmers, in addition to applications, across conforming systems.
 Toward this end, the POSIX.2a specifications expand the number and type
 of utilities specified, and enhance the features of a number of POSIX.2-
 specified utilities, to provide a consistent interactive environment.
 The consistent interactive environment does not include emerging
 technologies such as graphical user interfaces, which are under
 development by different standards groups.

 Parts of POSIX.2 go beyond the current service requirements and include a
 number of software development and debugging commands and utilities
 services.  These are included in the POSIX.2 specification because of the
 traditional development orientation of UNIX systems.  These software
 development and debugging services are not included in this clause
 because this clause includes more general and universal services, such as
 copying a file and reading a directory.

 Although the POSIX.2 and POSIX.2a specifications are still in draft
 stages, they are relatively complete, and portions of the emerging
 standard are believed to be mature and stable.

 When the commands, shell, and utilities specifications are completed and
 approved, the resulting IEEE POSIX.2 and POSIX.2a standards will be
 submitted to ISO/IEC JTC1 for adoption as international standards.  At
 that time, POSIX.2 and POSIX.2a will be combined into a single integrated
 international standard (ISO/IEC 9945-2).

 _I_E_E_E__P_1_0_0_3_._1_5                                                              e

 When completed, the IEEE P1003.15 standard will provide batch queueing     e
 extensions to various POSIX base standards.  These extensions define       e
 utilities, library routines, system administration interfaces, and an      e
 application-level protocol to address the following areas:                 e

     - Utilities for submission and management of requests                  e

     - System administration interfaces for the creation, management, and   e
       authorization of the network queueing and batch processing system    e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 184                              4 POSIX Open System Environment Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - language-independent programmatic (library) interfaces for           e
       application access to utilities and the queue and request database,  e
       and                                                                  e

     - Application-level network protocols                                  e

 4.10.5.3  Gaps in Available Standards

 There are no formal interapplication standards that address the remote
 access and execution of a system's command interfaces.  The Berkeley BSD
 UNIX de facto standard addresses all these service requirements, however.

 4.10.5.3.1  Public Specifications

 Public specifications that include the POSIX.2 and POSIX.2a, and go
 beyond these standards to also include the traditional UNIX-based command
 interfaces for electronic mail, remote command execution, file transfer,   e
 interprocess communications, shared memory, semaphores, and software       e
 development utilities are available from a number of organizations.        e
 These include:                                                             e

     - OSF's OSF/1 Application Environment Specifications (AES)             e

     - AT&T System V Interface Definition (SVID)                            e

     - X/Open's XPG3 specifications, Volume 1 and part of Volume 3


 4.10.6  POSIX OSE Cross-Category Services

 4.10.6.1  Internationalization

 The utilities described in the POSIX.2 specifications satisfy some         e
 requirements for standardized multilingual and multicultural support
 (e.g., localization requirements such as date formats and collation
 sequences, and support for international character sets).


 4.10.7  Related Standards

 None.                                                                      e










              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 4.10 User Command Interface Services                                  185








































































                                                               P1003.0/D14








               Section 5: POSIX OSE Cross-Category Services



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _F_r_i_t_z _S_c_h_u_l_z

 The POSIX reference model defines a set of conceptual system building
 blocks that collectively describes the Open System Environment.  Each
 building block provides a specific set of interfaces for access to their
 associated facilities and services.  There is another class of services
 and requirements, however, that may influence and/or impact the basic
 architectural building blocks; these are referred to as OSE Cross-
 Category Services.

 An OSE Cross-Category Service is a set of tools and/or features that,
 when applied, may have a direct affect on the operation of one or more of
 the Open System Components, but it is not in and of itself a standalone
 OSE component.  Examples of OSE Cross-Category Services include
 internationalization, security and privacy, administration, etc.
 Internationalization has a number of attributes that influence multiple
 OSE components; supporting multiple coded character sets, for example,
 will affect end-user interfaces, operational message input and output,
 screen display, data collating sequences in programming languages and
 database systems, etc.

 This section will deal with the general characteristics of OSE Cross-
 Category Services as applied to the OSE architectural components and to
 the profiles and domains that characterize application environments.  The
 specific impact/influence of an OSE Cross-Category Service will be
 described in the appropriate subclause of Section 4 that deals with
 individual OSE Components.

 Initially, this section will address Internationalization, Security and
 Privacy, and System Administration; however, it is anticipated that other
 OSE Cross-Category Services will be identified as the concept is applied
 to the model.

 This section describes issues that should be considered in writing
 profiles, and is organized so that subclauses for each OSE Cross-Category
 Service points to, and addresses issues adjacent to each of the service
 categories identified in Section 4.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5 POSIX OSE Cross-Category Services                                   187






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 These issues defined areas that need to be traded off to arrive at
 balanced solutions for a specific profile.  It is expected that the
 specific trades would be made by the profiler, but that this clause could
 give guidance for trading and could also be used to accumulate lessons
 learned.














































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 188                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 5.1  Internationalization

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _R_a_l_p_h _B_a_r_k_e_r

 _E_d_i_t_o_r'_s _N_o_t_e:  _A_l_m_o_s_t _a_l_l _i_n_s_t_a_n_c_e_s _o_f ``_m_u_s_t'' _i_n _t_h_i_s _c_l_a_u_s_e _h_a_v_e _b_e_e_n  e
 _c_h_a_n_g_e_d _t_o ``_s_h_o_u_l_d'' _w_i_t_h_o_u_t _f_u_r_t_h_e_r _d_i_f_f _m_a_r_k_s.                          e


 5.1.1  Overview and Rationale

 Historically, information systems intended for use within a particular
 national or cultural market have been designed specifically for the
 requirements of that market.  If the vendor or developer was based in a
 country other than that of the target market, this was typically
 accomplished through substantial re-engineering the features of an
 existing system designed for some other country, and doing so at
 considerable cost.  As the developer desired to market the system in
 additional countries, the process of re-engineering was repeated for each
 new national or cultural market.  Application software developers were
 faced with the same problem.  The very nature of this style of
 development produced little concern for portability across national or
 cultural boundaries, or interoperability between them.  Users or
 organizations that needed to operate in multiple national or cultural
 markets typically did so with multiple, generally incompatible,
 information processing systems.

 The interfaces provided by the POSIX Open System Environment (POSIX OSE)
 can be generalized, however, through the use of internationalization, to
 extend across national and cultural boundaries.  Such a model provides
 the foundation for international portability of application software,
 increased user portability, and enhanced interoperability and data
 exchange capabilities.  The task of internationalization is to ensure
 that the services provided by the POSIX OSE, and the interfaces between
 such services, are specified in such a way that they can be easily used
 all over the world.  Additionally, as the user is likely to require
 services from any or all of the service categories of the POSIX OSE,
 internationalization impacts all areas of the POSIX OSE, and should be
 viewed as an OSE Cross-Category Service.  Since the internationalization
 aspects of general OSE services and application program interface (API)
 services are similar for all of the POSIX OSE service categories, they
 are discussed here rather than repeating them in each of the services
 sections within this guide.

 The ability of the service categories of the POSIX OSE to support
 multiple natural languages, and the underlying cultural conventions, is a
 two step process.  These two steps are generally referred to as
 ``internationalization'' and ``localization.''  First, the interfaces
 between the service categories are generalized, so that they are not
 oriented to the requirements of any particular natural language or set of


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              189






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 cultural conventions (internationalization).  Then, facilities are
 provided by the POSIX OSE that allow the user to select the desired
 natural language and cultural conventions (localization).  Tools are
 provided to facilitate this process.

 Within this context, cultural conventions, while discussed more fully
 later in this clause, may be viewed as various aspects of how information
 is presented to the user.  Different cultures, for example, use different
 formats for dates and numeric values and use different currency symbols.
 The interfaces provided by the POSIX OSE should allow the information to
 be presented to the user in the appropriate format as well as the
 appropriate natural language.


 5.1.2  Scope

 The POSIX OSE provides services that are necessary to support users,
 irrespective of their particular natural language or cultural
 conventions.  While it is not expected that every implementation of the
 POSIX OSE would provide support for all possible natural languages and
 cultural conventions, the specification of the services and the
 interfaces within the POSIX OSE should not preclude such support.  In
 addition to the service and interface requirements described here, it
 should be noted that internationalization is affected by a number of
 elements that are beyond the scope of this guide.  Actual implementations
 of the internationalized POSIX OSE, for example, may need to consider the
 impact of multiple sets of governmental and regulatory agencies,
 international data communication standards and other elements which are
 presently not specified within the POSIX OSE, such as data portability
 between localized information processing systems.

 Service requirements differ from country to country and even between
 users within one country.  Many users, for example, may require the
 simultaneous support of multiple natural languages and cultural
 convention sets.  Therefore, the basic internationalization requirement
 within the POSIX OSE is to provide a set of services and interfaces that
 allow the user to define, select, and change between different culturally
 related application operating environments supported by the particular
 implementation.  Specifically:

     - The POSIX OSE should provide the means of adjusting the output of
       specific functions and utilities to support different natural
       languages, cultural conventions and character sets as may be
       required by the supported natural languages.

     - A user should have the capability to select an internationalized
       user environment that specifies a particular set of data
       presentation characteristics, including cultural conventions,
       character sets and native language.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 190                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - An implementation of the POSIX OSE should be able to concurrently
       support different applications functioning in different
       internationalized user environments, supplying different sets of
       natural languages, cultural conventions and character sets for
       different users.

     - The capability of supporting different internationalized user
       environments, and the associated natural languages, cultural
       conventions and character sets, should not require any changes to
       the logic of existing application programs.

     - The effect of the user selecting a new internationalized user
       environment, and its associated natural language, cultural
       conventions and character set, should be transparent to application
       programs.

     - The model should be flexible, to support future extensions and
       requirements.


 5.1.3  Reference Model

 Internationalization is an OSE Cross-Category Service, spanning all OSE
 service categories.  While various reference models have been used in
 published technical papers to depict internationalization issues, the
 internationalization services described in this clause conform to the
 POSIX OSE Reference Model.


 5.1.4  Service Requirements

 The POSIX OSE should provide services on different levels:  general
 service requirements to be satisfied for any requesting program; API
 service requirements to be satisfied at the application program interface
 for a specific program; and a set of tools to support the localization of
 systems and applications.  This subclause (5.1.4) will discuss these
 different service requirements in detail.  In examining these service
 requirements, it is helpful to draw a distinction between those services
 which are required to support the portability of an application platform
 across cultural boundaries, and those services which are required to
 support the portability of an application across one or more sets of
 cultural conventions which may be supported on a single application
 platform.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              191






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 5.1.4.1  General Service Requirements, Application Platform

 Internationalization requirements are focused on support and handling of:

     - Character sets and data representation

     - Cultural conventions

     - Natural language support

 5.1.4.1.1  Character Sets and Data Representation

 The character set for the English language can easily be satisfied by the
 standard ASCII character set (American Standard Code for Information
 Interchange).  The ASCII code uses 7 bits to uniquely identify each of
 the 95 available characters.  For European and American languages beside
 English, the number of local characters is much larger.  The far-east
 requirements for thousands of pictograms add yet another dimension to the
 coding rules and techniques.

 Different standards address the methods by which the local character
 repertoires can be coded for unique identification.  While replacement of
 seldom-used characters in the 7-bit codings can support a single
 additional language besides English, 8-bit coding schemes are used to
 satisfy multiple languages concurrently by assigning an additional 96
 graphic characters to the available repertoire.  An example is ISO 8859-1
 (the extended ASCII code), which can support all of western Europe,
 America, Australia, and other English speaking countries all over the
 world.  For Eastern Europe, Greece, Russia, Arabia, and many other
 countries, other 8-bit codes are defined.  Japan, China, Korea, and
 Taiwan have so many characters in their repertoire that 16 bits are
 needed to identify them clearly.  Work is under way to develop a multi-
 octet character set with up to 32 bits per coded character; this method
 will allow concurrent use of all possible languages in the same
 application.

 Because different coding schemes are used, it is important that the
 application platform have the potential capability of supporting all of
 them.  It is also important that the application platform has the
 capability to represent (display, print) the data correctly. It is also
 important that an application be able to determine in which coded
 character set data items are stored on disk or tape.  Otherwise, it is
 impossible for the application to interpret the data correctly.
 Currently the user must control the consistent use of the same coded
 character set within an application, but in the future the application
 platform should be able to provide identification methods for the coded
 character sets used for data storage, processing, communication, and
 presentation.  It might also be advantageous for the application to be
 able to prohibit users from updating data stored in one coded character


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 192                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 set with data in another coded character set since this would immediately
 corrupt data bases or flat files.  Therefore it may be necessary in the
 future to provide a method of announcing the coded character set in which
 data are stored, processed, communicated, and presented.

 The general service for support of character sets and data representation
 in an international environment are:

     (1)  Coded character set independence:  the ability of the
          application platform to input, store, manipulate, retrieve,
          communicate, and present data independent from the coding scheme
          used.  This includes 7-bit, 8-bit, 16-bit, and multi-octet coded
          character sets.

     (2)  Character set repository:  the ability of the application
          platform to maintain and access a central character set
          repository.  This repository contains all coded character sets
          used throughout the platform and specifies relevant information
          about them:

           - Code format:  the repository contains information, if
             characters are coded in 7 bits, 8 bits, 16 bits, or any other
             format.

           - Data class definition:  the definition that a character is
             considered numeric, alpha, etc., by the programming
             languages.  This classification can vary for the same
             character from country to country.

           - Collating rules:  different character sets have different
             coding for characters.  Thus, comparison of strings of such
             coded characters should follow rules defined for the specific
             character set.  Culturally dependent additional collating
             rules are discussed in 5.1.4.1.2.

           - Lower- to uppercase mapping:  this defines the rules of
             mapping, if for a specific character no upper- or lowercase
             is available.  Examples are the lower case umlauts which do
             not have uppercase representations in Switzerland; the
             uppercase forms are A, O, or U, respectively, followed by a
             lowercase ``e''.

           - Escapement rules:  some languages like Hebrew and Arabic are
             written from right to left; numbers within text in these
             languages are written from left to right.  It is necessary to
             store these escapement rules with the character set.

           - Presentation rules:  the application platform should have the
             ability of providing fallback presentation rules for the


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              193






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

             presentation of coded characters that have no associated
             graphic shape.

     (3)  Character set identifier:  the application platform should
          provide the ability to uniquely identify each coded character
          set to allow compatibility checks and translation or
          transliteration to and from other registered character sets.
          This ensures data integrity in the communication of data across
          computers and networks.

     (4)  Character set selection:  the application platform should allow
          the end-user or the application to select the coded character
          set to be used; otherwise, the application should automatically
          select a default coded character set according to preset
          parameters.  It should be possible to switch to other coded
          character sets and to invoke translation routines where
          required.

     (5)  Data announcement:  the application platform could benefit from
          having the ability to recognize the coded character set of data
          entities (files, messages, etc.).  One way of doing this is to
          store the character set identifier together with the data;
          standardization efforts are under way to formalize this process,
          with consideration being given to the level of granularity of
          such identification (e.g. file, word, character).  The
          announcement enables the application to prohibit updates with
          data coded in other character sets, thus ensuring data integrity
          even in distributed systems.

     (6)  Data presentation:  the application platform should be able to
          present data on different display or output devices, potentially
          according to rules in a repository, including escapement of
          characters and selection of different shapes.  Preparing data
          for presentation may involve extensive translation and
          transliteration due to potential hardware limitations of the
          printers and displays used in a particular installation.

     (7)  Data communication:  the application platform should be able to
          transmit and receive data from communication systems and to
          maintain the integrity of the information.  In an
          internationalized environment, this capability might include
          data translation due to different coded character sets being
          used by different service categories of the application
          platform.

     (8)  Data input:  the ability to enter data is not necessarily
          controlled by the application platform.  The complexity of the
          input of Asian languages though might strongly support the idea
          of a standardized input mechanism interface.  Depending on how


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 194                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          other internationalization service requirements are met, it
          might also be beneficial for input data to carry some form of
          character set identification.

 5.1.4.1.2  Cultural Conventions

 Besides using different characters and different languages, countries
 throughout the world have also developed quite different cultural
 conventions.  Even within one country we can find significantly different
 cultural environments.  The prime example is Switzerland, where French,
 German, Italian, and Rhaeto Romanic are officially accepted languages.
 Combined with the language preferences are conventions about the formats
 of time, date, numeric values, and measuring systems.  Currency symbols,
 paper formats, hyphenation, and collating are dependent on cultural
 conventions.  End-user-oriented applications have to address these issues
 to provide a familiar local view, which helps to prevent operating
 errors.

 The general service requirements for cultural conventions are:

     (1)  Cultural convention repository:  The application platform should
          have the ability to store and access rules and conventions for
          cultural entities.  These might be areas with a common language,
          geographic areas, or areas with common cultural or historic
          background.  The repository should contain specifications and
          presentation rules for:

           - Date and time formats:  indicating the formats associated
             with the particular cultural entity.  For example, while in
             the US the date is expressed in the format month/day/year,
             the European preferred format is year-month-day for data
             processing purposes and day-month-year in personal use.
             Japan counts the years according to the reign of the current
             emperor.  Additionally, twenty-four-hour clocks, which are
             prevalent in Europe, are commonly used only in military
             circles in the US, while the terms ``am'' and ``pm'',
             denoting morning and afternoon, are used by the general
             public. These are only a few examples for the cultural
             differences in this area.  The application platform should be
             able to store the preferred forms for date and time for a
             specific cultural entity and make it available upon request
             in this format.

           - Week and day numbering:  in Europe, the week starts on
             Monday, in the US on Sunday.  The application platform should
             be able to supply the requesting program with the needed
             information, potentially from a repository according to
             specified rules.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              195






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

           - Formats of numeric fields:  handling of numeric fields in
             unfamiliar formats is one of the major reasons for human
             errors.  The application platform should provide the service
             to format the values according to specifications in the
             repository.  The characters that signify the decimal point
             (comma, period, etc.) should be defined, as well as the
             number of decimals, the grouping of digits before the decimal
             point and the presentation of negative values.

           - Currency symbols and field length:  the handling of currency
             symbols in the different cultural areas should be provided by
             the general internationalization services.  The currency
             symbols might be more than one digit long and can appear
             before or after the currency field.  The format of currency
             fields might differ from that of numeric fields; for example,
             in Portugal the $-sign is used as the decimal point.
             Information about these conventions should be stored in the
             repository and be used by the application platform for local
             formatting of currency fields.  Not necessarily a service,
             but similarly important, is the understanding, that due to
             the value of different currencies, the field lengths should
             be considered carefully.  Also some currencies do not have
             decimals (e.g., Italian Lira).

           - Paper formats:  internationally usable and portable
             applications should be able to print on different paper
             formats.  While quart format is predominant in the US and the
             far east, the DIN standardized A-formats are used in Europe.
             Printer drivers should be able to adjust their output to
             local formats, defined in the cultural convention repository.

     (2)  Cultural repository selection:  these repositories should be
          available to all applications.  Users and applications should be
          able to select a repository from the application platform; a
          default value should be provided if no selection is made.  An
          additional service allows dynamic switching to other
          repositories upon user or program requests.

     (3)  Collating rules:  besides the generic binary and character-set-
          dependent sorting rules, the application platform should have
          the ability to sort data according to local rules, defined in
          the repository.  An example for culture-dependent collating
          rules is the handling of umlauts; while they are sorted with the
          base characters in Austria, they are sorted at the end of the
          alphabet in Sweden.  Adding complexity, they can be sorted
          differently within one country between normal business use, such
          as dictionaries, and in telephone books.  Other idiosyncrasies
          are the sorting of one character as two (the German ``sharp-s''
          sorts as ``sz'' in Austria and ``ss'' in Germany), or two


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 196                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          characters as one (the Spanish ``ch'' sorts as one character),
          or the position of accented characters in a string, and more.
          User-defined collating tables in the cultural convention
          repository allow culture or application-dependent sorting
          services.

 5.1.4.1.3  Natural Language Support

 The POSIX OSE should give users the ability to select a natural language
 for their dialogue with the system and applications.  While it is
 unrealistic to expect all application platforms to support all possible
 natural languages, error messages, online documentation and help
 facilities, selection menus, and the relevant user interaction with these
 services should be prepared for translation into the supported user-
 selectable natural language.  Additionally, the POSIX OSE should support
 differences between the natural language selected by the user for
 interaction with the application platform and that selected for use
 within a particular application. For word- and text-processing, the
 service includes hyphenation and spell checking with possible thesaurus
 support in different languages.  The problem is complicated by the fact
 that data can contain text in different languages in the same document.

 The service requirements for natural language support are:

     (1)  Multilingual capability:  the application platform should be
          able to support more than one language simultaneously.  For
          example, one process might be providing French language
          capabilities while another process operated in Japanese. The
          application platform should be able to let users select their
          preferred languages for communication with the application and
          allow them to switch dynamically to another language.  The
          application platform also should have the capability to assign a
          default language, based on parameters for the application
          platform, the specific workstation, the user identification, or
          the application.

     (2)  Natural language message system:  the application platform
          should have the capability to present (display, print, ...)
          messages, menus, forms, and online documentation in the
          language, selected by the user.  The application platform should
          be able to support multiple languages simultaneously for
          different users and it should allow the user to switch from one
          language to another.  The following problems also should be
          handled correctly:

           - The program code of the application should be able to be
             independent from any particular natural language, presenting
             messages in the natural language used within the
             internationalized user environment selected by the user.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              197






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

           - Variable message length:  the application platform should
             support the presentation of messages of variable length, as
             translation into other languages changes the length of the
             message; English text is usually quite short compared to the
             same text in, e.g., German or Finnish.  Ample room should be
             available in the display field to accommodate this variation.

           - Inserted parameters and word order:  the application platform
             should have the capability of inserting variable parameters
             into messages at the location appropriate for the user
             selected natural language.

     (3)  Support of local keyboards:  the application platform should be
          able to correctly interpret the input from keyboards that have
          been modified locally to support the local character sets.

     (4)  Local language user interaction:  the application should be able
          to accept solicited input from the user in the language selected
          by the user, without dependence within the application logic on
          a particular natural language or set of cultural conventions.
          For example, many applications use the first characters of
          prompts to make selections; this method is not acceptable in an
          internationalized system.  The translation process changes the
          prompts and with them their first character; more than one
          prompt could have the same start-character and the program logic
          would not work.  Multiple languages should be supported
          simultaneously.

 5.1.4.2  API Service Requirements

 All the general services defined in 5.1.4.1 should be accessible from the
 applications through requests to the application program interface.  The
 API service requirements can be structured in the same way as the general
 requirements, which they call for.

 5.1.4.2.1  Cultural Conventions

     - Cultural convention invocation:  the application platform should
       allow the application to invoke a specific cultural convention from
       the repository.  It should automatically invoke the default
       convention set, if no selection is made by the application.

     - Cultural convention change:  when requested by the application or
       the user, the application platform should change the used cultural
       convention dynamically.

     - Provide local values:  upon request from the application, the
       application platform should return local formats for time, date,
       calendar, numeric fields, currency fields and symbols.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 198                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Local sort and comparison:  when requested by the application, the
       application platform should compare and sort data according to the
       local collating rules defined in the cultural convention
       repository.

 5.1.4.2.2  Natural Language Support

     - Language selection:  the application platform should present
       messages, menus, forms, online documentation, and user interaction
       in the natural language selected by the user or automatically by
       the system based on preset parameters for the application, the
       session, the user, or the system.

     - Change of language:  upon request from the user, the application
       platform should be able to dynamically change, prior to the
       invocation of a particular user application, the language used for
       messages, menus, forms, online documentation, and user
       interactions.

 5.1.4.3  Localization Tools Requirements

 Internationalization of application platforms and applications is the
 basis for their localization in the different countries.  It is important
 for the user that this localization can be performed in a well prepared,
 organized way without the need to know the internal structure of the
 application platform or the application.  The following requirements for
 localization tools are key to successful localization of application
 platforms and applications:

     - Character set repository tools:  tools should be provided to set up
       and maintain character set repositories.  They also should allow
       the addition of new character sets to the repository.

     - Cultural convention repository tools:  tools should be provided to
       set up and maintain the cultural convention repositories.  Addition
       of new cultural environments should be possible.  User-definable
       collation tables are essential parts of these repositories; tools
       to define and maintain them should be offered.

     - Translation support tools:  facilities for the set-up and
       maintenance of local language message files, menus, forms, online
       documentation, and user interaction tables should be provided.  The
       addition of new supported languages should be allowed by such
       tools.  Additionally, any such translation tools should allow
       revision control, so that only new or changed text would require
       translation for new software releases.

                                                                            e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              199






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 5.1.5  Standards, Specifications, and Gaps

 There are not many standards available that deal with
 internationalization.  The majority of current standards describe
 character sets, both for control characters and for graphic characters in
 different coding schemes (7-bit, 8-bit, etc.).  A few standards address
 the formats of time and date, and some standards touch peripherally on
 the subject of data announcement.

 An example of how cultural conventions and languages are currently
 supported is the _l_o_c_a_l_e() function.  It allows the application developer
 to select portions or all of predefined support features for national
 languages and local cultural conventions.  The portions, called
 categories, correspond to the areas of functionality; presently supported
 are character classification, collation sequence, date/time format,        e
 monetary format, and numeric format.  Other categories, such as message    e
 handling, are likely to be implemented, too.  Other systems have started
 to implement similar philosophies of general services to support local
 cultural conventions.

 5.1.5.1  Current Standards

 5.1.5.1.1  International Standards

     - ISO 646: 1983, _I_S_O _7-_B_i_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t _f_o_r _I_n_f_o_r_m_a_t_i_o_n
       _I_n_t_e_r_c_h_a_n_g_e

       Defines the binary representation of 128 control, (Latin) alphabet,
       digit, and symbol characters.  Describes in general the use of the
       control characters.  Describes option of national replacement
       characters.

     - ISO 2014: 1976, _W_r_i_t_i_n_g _o_f _C_a_l_e_n_d_a_r _D_a_t_e_s _i_n _A_l_l-_n_u_m_e_r_i_c _F_o_r_m

       This international standard specifies the writing of dates of the
       Gregorian calendar in all-numeric form, signified by the elements
       year, month, and day.

     - ISO 2022: 1986, _I_S_O _7-_B_i_t _a_n_d _8-_B_i_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s--_C_o_d_e
       _E_x_t_e_n_s_i_o_n _T_e_c_h_n_i_q_u_e_s

       Defines techniques for expanding the number of characters
       represented by the base character set.

     - ISO 3307: 1975, _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _T_i_m_e _o_f _t_h_e _D_a_y

       This international standard is designed to establish uniform time
       representation based upon the 24-hour timekeeping system.  It
       provides a means for representing local time of the day and


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 200                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14


               Table 5-1  -  Internationalization Standards                 e
 __________________________________________________________________________________________________________________________________________________  e
              Service                Type      Specification       Subclausee
 ___________________________________________________________________________e

 Character set/data representation    S     ISO 646, ISO 2022,    e5.1.5.1  ee       ee
                                            ISO 4031, ISO 4217,   e         e
                                            ISO 4873, ISO 6093,   e         e
                                            ISO 6429, ISO 6936,   e         e
                                            ISO 6937-1,           e         e
                                            ISO 6937-2,           e         e
                                            ISO 7350, ISO 8601,   e         e
                                            ISO 8859-_n (1-9),     e         e
                                            CCITT T.61, GB 2312,  e         e
                                            JIS X 0208,           e         e
                                            KS C 5601             e         e

 Character set/data representation    E     ISO DIS 10367,        e5.1.5.2  ee       ee
                                            ISO DIS 10646         e         e

 Cultural convention                  S     ISO 2014, ISO 3307    e5.1.5.1  ee       ee

 Natural language support             E     ISO/IEC 9995-x,       e5.1.5.2  ee       ee
                                            CSA-Z243.200-88       e         e
 __________________________________________________________________________________________________________________________________________________  e


       Universal Time in digital form for the purpose of interchanging
       information among data systems.

     - ISO 4031: 1987, _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _L_o_c_a_l _T_i_m_e _D_i_f_f_e_r_e_n_t_i_a_l_s

       This international standard specifies a standard means for
       representing local time differentials to facilitate interchange of
       data among data systems.

     - ISO 4217: 1987, _C_o_d_e_s _f_o_r _t_h_e _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _C_u_r_r_e_n_c_i_e_s _a_n_d
       _F_u_n_d_s

       Specifies the representation of currencies and currency symbols

     - ISO 4873: 1986, _I_S_O _8-_B_i_t _C_o_d_e _f_o_r _I_n_f_o_r_m_a_t_i_o_n _I_n_t_e_r_c_h_a_n_g_e--
       _S_t_r_u_c_t_u_r_e _a_n_d _R_u_l_e_s _f_o_r _I_m_p_l_e_m_e_n_t_a_t_i_o_n

       Outlines the structure of the ISO 8-bit code and rules for
       implementation.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              201






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - ISO 6093: 1985, _P_r_e_s_e_n_t_a_t_i_o_n _o_f _N_u_m_e_r_i_c_a_l _V_a_l_u_e_s _i_n _C_h_a_r_a_c_t_e_r
       _S_t_r_i_n_g_s _f_o_r _I_n_f_o_r_m_a_t_i_o_n _I_n_t_e_r_c_h_a_n_g_e

       Specifies three presentations of numerical values, which are
       represented in character strings in a form readable by machine, for
       use in interchange between data processing systems.  Also provides
       guidance for developers of programming languages standards and
       Implementor's of programming products.  These representations are
       recognizable by humans, and thus may be useful in communication
       between humans.

     - ISO 6429: 1988, _I_S_O _7-_B_i_t _a_n_d _8-_B_i_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s--_C_o_n_t_r_o_l
       _F_u_n_c_t_i_o_n_s _f_o_r _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s

       Defines control functions and their coded representations for use
       in a 7-bit code, an extended 7-bit code, an 8-bit code, or an
       extended 8-bit code.  Specifies a C0 set, a C1 set, control
       functions derived there from, and a number of independent control
       functions.

     - ISO 6936: 1988, _C_o_n_v_e_r_s_i_o_n _b_e_t_w_e_e_n _t_h_e _T_w_o _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _o_f
       _I_S_O _6_4_6 _a_n_d _I_S_O _6_9_3_7-_2 _a_n_d _t_h_e _C_C_I_T_T _I_n_t_e_r_n_a_t_i_o_n_a_l _T_e_l_e_g_r_a_p_h
       _A_l_p_h_a_b_e_t _N_o.  (_I_T_A) _2

       Specifies the rules for conversion between ITA 2 representation of
       58 characters and the ISO 646 representation of 128 characters.

     - ISO 6937-1: 1983, _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _T_e_x_t _C_o_m_m_u_n_i_c_a_t_i_o_n--_P_a_r_t
       _1:  _G_e_n_e_r_a_l _I_n_t_r_o_d_u_c_t_i_o_n

       Defines terms and concepts used in describing and using code
       representations of character sets.

     - ISO 6937-2: 1983, _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _T_e_x_t _C_o_m_m_u_n_i_c_a_t_i_o_n--_P_a_r_t
       _2:  _L_a_t_i_n _A_l_p_h_a_b_e_t_i_c _a_n_d _N_o_n-_a_l_p_h_a_b_e_t_i_c _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r_s

       Defines a repertoire of Latin alphabetic and non-alphabetic
       characters.  Specifies binary representation of the characters.
       Specifies rules for the definition and use of character sets that
       are subsets of the repertoire.

     - ISO 7350: 1984, _R_e_g_i_s_t_r_a_t_i_o_n _o_f _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r _S_u_b_r_e_p_e_r_t_o_i_r_e_s

       Specifies the procedures for preparing, registering, publishing,
       and maintaining the register of graphic character sets that are
       composed from the character repertoire of ISO 6937 and the
       procedures for assigning identifiers to the sets.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 202                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - ISO 8601: 1988, _R_e_p_r_e_s_e_n_t_a_t_i_o_n _o_f _D_a_t_e_s _a_n_d _T_i_m_e_s

       Specifies the representation of dates A.D.  in the Gregorian
       calendar and times and representation of periods of times.
       Applicable whenever dates and times are included in information
       interchange.

     - ISO 8859-x: 1987, _8-_B_i_t _S_i_n_g_l_e-_B_y_t_e _C_o_d_e_d _G_r_a_p_h_i_c _C_h_a_r_a_c_t_e_r _S_e_t_s

       Specifies a set of up to 191 graphic characters by means of a
       single 8- bit byte.  The versions (``-x'') indicate different coded
       character sets:

          -1 Latin Alphabet No.  1

          -2 Latin Alphabet No.  2

          -3 Latin Alphabet No.  3

          -4 Latin Alphabet No.  4

          -5 Latin/Cyrillic Alphabet

          -6 Latin/Arabic Alphabet

          -7 Latin Greek Alphabet

          -8 Latin/Hebrew Alphabet

          -9 Latin Alphabet No.  5                                          e

     - CCITT T.61, 1985:  _C_h_a_r_a_c_t_e_r _R_e_p_e_r_t_o_i_r_e _a_n_d _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t_s
       _f_o_r _t_h_e _I_n_t_e_r_n_a_t_i_o_n_a_l _T_e_l_e_t_e_x _S_e_r_v_i_c_e

       Describes detailed definitions of the repertoires of graphic
       characters and control functions to be used in the international
       Teletex service.  The means by which supplementary character
       repertoires are defined are also described.

 5.1.5.1.2  Regional Standards

 Presently, no regional internationalization standards which relate to the
 scope of this guide have been adopted.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              203






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 5.1.5.1.3  National Standards

 Many of the international ISO standards have ``twins'' in the national
 standards bodies; i.e., the same text is given a local standard
 identification.  Also, national standards bodies have often developed
 standards for local representation of time, date, and currency.  The
 implementation of these standards into an internationalized system is a
 prime example of localization.

 Here are some standards that have no international equivalent:

     - GB 2312: 1980, Chinese national character set standard

     - JIS X 0208: 1983, Japanese national character set standard

     - KS C 5601: 1987, Korean national character set standard

 5.1.5.2  Emerging Standards

 5.1.5.2.1  International Standards

 The rapid development of business opportunities in the Pan-European and
 the Asian market has spawned a wealth of activities to develop standards
 for the support of internationalization in the field of information
 technology.  These emerging standards deal with character sets, language
 neutral user interfaces, and communication.

     - ISO DIS 10646:  _M_u_l_t_i_p_l_e _O_c_t_e_t _C_o_d_e_d _C_h_a_r_a_c_t_e_r _S_e_t

       This standard will permit the presentation of all of the world's
       scripts in computer based systems, and their unambiguous
       interchange between one system or person and another.  It is
       applicable to the representation, processing, storage and
       presentation of the written form of the languages of the world.

     - ISO/IEC DIS 10367:  _R_e_p_e_r_t_o_i_r_e _o_f _S_t_a_n_d_a_r_d_i_z_e_d _C_o_d_e_d _G_r_a_p_h_i_c
       _C_h_a_r_a_c_t_e_r _S_e_t_s _f_o_r _U_s_e _i_n _8-_B_i_t _C_o_d_e_s

       This standard specifies a unique graphic character set for use as
       G0 set and a series of coded graphic character sets of up to 96
       characters for use as the G1, G2, and G3 sets in versions of ISO
       4873.  All sets specified in this standard are shown as elements of
       an 8-bit code.

     - ISO/IEC CD 9995-x:  _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y--_K_e_y_b_o_a_r_d _L_a_y_o_u_t_s _f_o_r
       _T_e_x_t _a_n_d _O_f_f_i_c_e _S_y_s_t_e_m_s

       This family of standards defines the layout of keyboards so that
       they can be used for input of multilingual information.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 204                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 5.1.5.2.2  Regional Standards

 The European Community is in the process to define European standards,
 called EN (Europaeische Norm).  No internationalization standards have
 yet been adopted.

 5.1.5.2.3  National Standards

 National standards under development which relate to internationalization
 include:

     - CSA-Z243.200-88:  _C_a_n_a_d_i_a_n _N_a_t_i_o_n_a_l _K_e_y_b_o_a_r_d _S_t_a_n_d_a_r_d _f_o_r _t_h_e
       _E_n_g_l_i_s_h _a_n_d _F_r_e_n_c_h _L_a_n_g_u_a_g_e_s _i_n _T_e_x_t _a_n_d _O_f_f_i_c_e _S_y_s_t_e_m_s

 5.1.5.3  Gaps in Available Standards

 5.1.5.3.1  Public Specifications

 The PC character set was defined at a time, when the international
 standards for single-byte, 8-bit character sets were not available yet.
 Therefore, the PC character set was accepted and still is a de facto
 standard in the PC world.  The concept of different code pages has been
 implemented in MS-DOS and WINDOWS-3 is using ISO 8859-1 internally for
 compatibility reasons with other systems.  Some companies have gone
 similar routes and developed their own, multilingual character sets for
 specific applications, the general trend is clearly towards ISO standards
 wherever they exist.

 A consortium of software and hardware companies is developing
 ``Unicode,'' a 16-bit character set standard for broad international use.  e

 5.1.5.3.2  Unsatisfied Service Requirements                                e

 While the character set arena is heavily populated, very little work is
 done in other areas of internationalization of products.  Standards
 should be developed for:

     - Cultural conventions repository

     - Application program interface services for cultural conventions

     - Application program interface services for character set handling

     - Multilingual collating rules

     - Input methods interface for Asian languages

     - Standards for message delivery systems



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              205






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Data announcement standards

 Additionally, no standards currently exist that support the following
 character set and data representation functionality:

     (1)  Character set invocation:  the application platform should allow
          the application to invoke a specific character set from the
          character set repository.  It should automatically invoke the
          default character set, if no selection is made by the
          application.

     (2)  Character set changes:  When requested by the application, the
          character set should be changed dynamically.

     (3)  Character set identifier:  the application program should be
          able to write the character set identifier to data and should be
          able to retrieve the identifier for requested data.

     (4)  Character set identifier comparison:  the application platform
          should, upon request from the application or automatically,
          compare the character set identifiers of interacting data in the
          application (input, processing, data storage, communication, and
          output).

     (5)  Character set translation:  the application platform should
          provide translation of character sets, when requested by the
          application or automatically, when detecting a mismatch in the
          comparison process.


 5.1.6  OSE Cross-Category Services

 Not applicable.


 5.1.7  Related Standards

 The nature of internationalization as being a cross-component facility is
 that it affects just about every element in the information processing
 world.  Thus, almost all standards in this environment are related to the
 subject.  Here we will point out a few major families of standards,
 strongly related to internationalization.

     - ISO DIS 8613:  Office Document Architecture and Interchange Format
       (ODA)

       This family of standards, ODA/ODIF, consist of:




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 206                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          1.2   Introduction and General Principles

          2.2   Document Structures

          3     Document Processing Reference Model

          4.2   Document Profile

          5.2   Office Document Interchange Format

          6.2   Character Content Architectures

          7     Raster Graphics Content Architectures

          8     Geometric Graphics Content Architectures

     - ISO 8824: 1987, _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _A_b_s_t_r_a_c_t _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e _A_S_N._1

       Specifies a notation for the definition of abstract syntaxes,
       enabling Application Layer standards to define the types of
       information they need to transfer using the Presentation service.
       It also specifies a notation for the specification of values of a
       defined type.

     - ISO 8825: 1987, _S_p_e_c_i_f_i_c_a_t_i_o_n _o_f _B_a_s_i_c _E_n_c_o_d_i_n_g _R_u_l_e_s _f_o_r _A_b_s_t_r_a_c_t
       _S_y_n_t_a_x _N_o_t_a_t_i_o_n _O_n_e (_A_S_N._1)

       Defines a set of encoding rules that can be applied to values of
       types defined using the notation specified in ASN.1.  Application
       of these encoding rules produce a transfer syntax for such values.
       It is implicit in the specification of these encoding rules that
       they are also be used for decoding.

     - All programming language standards, since programming languages
       have to support internationalization, and have to work correctly in
       localized environments.  Their generated code itself has to work
       ``localized.''

                                                                            e












              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.1 Internationalization                                              207






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS




















































              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 208                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 5.2  System Security Services

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _M_i_c_h_e_l_l_e _A_d_e_n


 5.2.1  Overview and Rationale

 Information is the key to successful use of a system.  For example, if
 used effectively and efficiently, information may be used to underpin
 enhanced service and to aid the derivation of strategic plans.  Much of
 this information, for example, personal customer details and business
 financial plans, will be of a sensitive nature.

 Although authorized users may be able to take advantage of the POSIX Open
 System Environment (OSE) to increase productivity and efficiency,
 unauthorized individuals may also be able to take advantage of the OSE to
 steal, manipulate or to deny others access to information held within the
 system, or to deny involvement in some transaction performed via the
 system.

 Security services must therefore be provided within the system if it is
 to prevent these unauthorized activities.  To achieve an optimum degree
 of confidence in the correctness and effectiveness of a system's security
 services, a system specific security policy must be derived and
 appropriate security functionality designed into the system at the
 beginning of its life cycle.

 A relatively high degree of protection for ordinary computer systems can
 be achieved if system administrators correctly configure and maintain the
 system according to recommended security guidelines and practice, such as
 those described within the _X/_O_p_e_n _S_e_c_u_r_i_t_y _G_u_i_d_e.  However, additional
 security facilities must be supported within the system to achieve
 protection against the small percentage of attackers who are noncasual,
 and who are determined to breach the security of the system.  It is the
 intent of the security extensions to the base POSIX interface standard to
 support these additional security facilities.

 The four basic security objectives of a system are to maintain:

     - Confidentiality.  The system must prevent unauthorized viewing of
       data.

     - Integrity.  The system must prevent unauthorized alteration or
       deletion of data.

     - Availability.  The system must ensure that authorized users are not
       prevented from accessing and processing data.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.2 System Security Services                                          209






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Accountability.  The system must ensure that users are made
       accountable for their actions, for example to ensure that users are
       correctly billed for system usage.  See also 5.3.4.11.               e

 Different user groups may place different emphases upon these four basic
 security objectives.  For example, the military security sector may place
 more importance upon confidentiality than accountability while,
 correspondingly, the commercial sector may place more importance upon
 accountability than confidentiality.


 5.2.2  Scope

 One of the goals of system security is to provide defense in depth, such
 that if one layer of security is breached then further layers of security
 will limit and/or prevent unauthorized activities within the system.

 To achieve a high degree of confidence in the correctness and
 effectiveness of the security of a system that will be processing
 sensitive information, security must be designed into the system at the
 beginning of its life cycle.

 A System Security Policy (SSP) defines what it means for a specific
 system to be ``secure'' and, as such, forms the basic security input into
 the system lifecycle.  Specification of an SSP is therefore axiomatic to
 the design of a secure system.

 Although the SSP defines what security measures will be provided within
 the system, it is the system design documentation that defines how these
 security measures will actually be implemented.

 One aspect of an SSP may be that it mandates conformance with the POSIX
 security extensions.

 Security interface specifications are intended to assist in the            e
 construction of a secure system.  They do not, in isolation, provide any
 protection against threats to a system.


 5.2.3  Reference Model

 The reference model for security is the same as the model shown in         e
 Figure 3-3.  Security has an impact on all of the APIs and EEIs in the     e
 model.                                                                     e







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 210                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 5.2.4  Service Requirements

 Through an analysis of the potential threats and requirements of the
 system, the system security objectives and hence the necessary System
 Security Policy (SSP) rules may be derived.  This analysis must also take
 into account appropriate corporate, legal, and standardization
 requirements.

 System confidentiality, integrity, availability, and accountability may
 be supported by the following security objectives:

 _T_e_c_h_n_i_c_a_l__S_e_c_u_r_i_t_y__O_b_j_e_c_t_i_v_e_s

     - Identification and Authentication.  A system entity, such as a user
       or system element, must prove that its claimed identity is
       legitimate, such that another system entity may place confidence in
       that claimed identity.

     - Access Control.  Access to system resources will be restricted to
       authorized entities only.  Residual data contained within an object
       will be securely erased before it may be reused by a system entity.

     - Accountability and Audit.  System users must be made accountable
       for their actions.  Audit trails of these actions will then be
       maintained and utilized such that unauthorized system activity will
       be detected.

     - Accuracy.  The system must ensure that the correctness and
       consistency of security-relevant information is maintained.

     - Availability.  System resources will be provided to users in a
       consistent and reliable manner.

     - Data Exchange.  Data transmitted between system users and/or
       elements will be protected from unauthorized interference or
       viewing.  Originators and recipients of data will be authenticated
       and will be able to mutually prove their respective participation
       in the transaction.

 _N_o_n_t_e_c_h_n_i_c_a_l__S_e_c_u_r_i_t_y__O_b_j_e_c_t_i_v_e_s

     - Assurance.  The security of the system must be specified, designed,
       implemented, tested, and maintained in such a way that confidence
       can be placed in the correct and effective operation of the system.
       Also, procedures must be specified to ensure continued confidence
       in the security of the system in the event that the system is
       modified in some manner.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.2 System Security Services                                          211






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Security Roles and Responsibilities.  Security activities must be
       partitioned and allocated to identifiable security administrators
       who will then be responsible for ensuring that their allocated task
       is satisfactorily performed.

     - Secure Operating Procedures.  Procedures must be written that will
       guide system administrators and users as to the correct procedure
       to follow in the event of some security-relevant occurrence.

 5.2.4.1  Application Programming Interface Services

                                                                            e

 The POSIX security interfaces will support Audit, Privilege,
 Discretionary Access Control (DAC), Mandatory Access Control (MAC), and
 Information Labels (ILs).                                                  e

 The audit services include:                                                e

     - Ability to record the user identification for actions within an      e
       audit trail                                                          e

     - Ability to process the audit trail                                   e

     - Ability to use the audit trail to generate alarms                    e

 The privilege control services include:                                    e

     - Ability to grant users only the minimal security required to         e
       perform a task                                                       e

 This will minimize the impact of a subverted security administrator or     e
 unauthorized usage of a security administrator role.                       e

 The discretionary access controls (DAC) provide the following services:    e

     - Ability to control fine-grained user access to objects               e

     - Ability to provide extended user access bits beyond the traditional  e
       user-group-other                                                     e

     - Ability to support access control lists (ACL)                        e

 The mandatory access controls (MAC) and information labels (IL) support    e
 policies for labeling:                                                     e

     - Ability to associate a MAC label with an object                      e




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 212                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Ability to label information (e.g., physical document handling       e
       restrictions)                                                        e

 5.2.4.2  External Environment Interface Services

 _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s:  _T_h_i_s _s_u_b_c_l_a_u_s_e _w_i_l_l _b_e _p_r_o_v_i_d_e_d _i_n _a _l_a_t_e_r _d_r_a_f_t.      e
 _M_o_c_k _b_a_l_l_o_t _r_e_v_i_e_w_e_r_s _a_r_e _w_e_l_c_o_m_e _t_o _s_u_b_m_i_t _c_o_m_m_e_n_t_s _o_n _t_h_e _t_y_p_e_s _o_f       e
 _s_e_r_v_i_c_e_s _r_e_q_u_i_r_e_d _a_t _t_h_e _E_E_I.                                              e


 5.2.5  Standards, Specifications, and Gaps

 Table 5-2 lists the current, emerging, and gaps in security standards.     e


                     Table 5-2  -  Security Standards                       e
 __________________________________________________________________________________________________________________________________________________  e
               Service           Type    Specification     Subclause        e
       _____________________________________________________________        e

       System Security            E     IEEE P1003.6 API   5.2.5.2          eee

       Access Control             E     ISO/IEC 8613       5.2.5.2          eee

       Directory Authorization    S     CCITT X.509        5.2.5.1          eee

       Security                   G     ECMA CMA 138       5.2.5.3          eee

       Trusted Systems            G     DOD 5200.28-STD    5.2.5.3          eee
 __________________________________________________________________________________________________________________________________________________  e


 5.2.5.1  Current Standards                                                 e

 ISO 7498-2, _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_c_o_n_n_e_c_t_i_o_n   e
 _R_e_f_e_r_e_n_c_e _M_o_d_e_l, _S_e_c_u_r_i_t_y _A_r_c_h_i_t_e_c_t_u_r_e.                                    e

 ISO/IEC 8613, _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y--_T_e_x_t _a_n_d _O_f_f_i_c_e _S_y_s_t_e_m_s--_O_f_f_i_c_e      e
 _D_o_c_u_m_e_n_t _A_r_c_h_i_t_e_c_t_u_r_e (_O_D_A) _a_n_d _I_n_t_e_r_c_h_a_n_g_e _F_o_r_m_a_t.                        e

 CCITT X.509, _M_e_s_s_a_g_e _H_a_n_d_l_i_n_g _S_y_s_t_e_m, _I_S_O/_C_C_I_T_T _X._4_0_0 _D_i_r_e_c_t_o_r_y            e
 _A_u_t_h_e_n_t_i_c_a_t_i_o_n _F_r_a_m_e_w_o_r_k.                                                  e

 ECMA CMA 138, _S_e_c_u_r_i_t_y _I_n _O_p_e_n _S_y_s_t_e_m_s--_D_a_t_a _E_l_e_m_e_n_t_s _a_n_d _S_e_r_v_i_c_e          e
 _D_e_f_i_n_i_t_i_o_n_s.                                                               e






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.2 System Security Services                                          213






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 5.2.5.2  Emerging Standards                                                e

 _I_n_f_o_r_m_a_t_i_o_n _R_e_t_r_i_e_v_a_l, _T_r_a_n_s_f_e_r _a_n_d _M_a_n_a_g_e_m_e_n_t _F_o_r _O_S_I--_D_r_a_f_t _A_c_c_e_s_s       e
 _C_o_n_t_r_o_l _F_r_a_m_e_w_o_r_k, _I_S_O/_I_E_C _S_C_2_1/_W_G_1.                                       e

 _D_r_a_f_t _A_d_d_e_n_d_u_m _t_o _I_S_O _8_6_1_3 _O_n _S_e_c_u_r_i_t_y                                     e

 _T_h_e _P_1_0_0_3._6 _s_c_o_p_e _i_s _l_i_m_i_t_e_d _t_o _s_e_c_u_r_i_t_y _e_x_t_e_n_s_i_o_n_s _f_o_r _t_h_o_s_e _i_n_t_e_r_f_a_c_e_s   e
 _d_e_f_i_n_e_d _w_i_t_h_i_n _t_h_e _b_a_s_e _P_O_S_I_X _i_n_t_e_r_f_a_c_e _s_p_e_c_i_f_i_c_a_t_i_o_n (_P_O_S_I_X._1 {_2}).       e
 _I_s_s_u_e_s _n_o_t _a_d_d_r_e_s_s_e_d _w_i_t_h_i_n _t_h_e _P_1_0_0_3._6 _s_c_o_p_e _i_n_c_l_u_d_e _n_o_n_i_n_t_e_r_f_a_c_e-        e
 _s_p_e_c_i_f_i_c _a_r_c_h_i_t_e_c_t_u_r_a_l _a_s_s_u_r_a_n_c_e _i_s_s_u_e_s _a_n_d _c_o_m_m_u_n_i_c_a_t_i_o_n_s _s_e_c_u_r_i_t_y.       e

 _5._2._5._3  Gaps in Available Standards                                       e

 _T_h_e _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y _S_e_c_u_r_i_t_y _E_v_a_l_u_a_t_i_o_n _C_r_i_t_e_r_i_a, Version 1.2, 28   e
 June 1991.                                                                 e

 US DoD, DOD 5200.28-STD, _T_r_u_s_t_e_d _C_o_m_p_u_t_e_r _S_y_s_t_e_m _E_v_a_l_u_a_t_i_o_n _C_r_i_t_e_r_i_a.      e

 Trusted Network Interpretation                                             e

 Trusted Database Interpretation                                            e

 Computer Security Subsystem Interpretation                                 e



























              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 214                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 5.3  Information System Management

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _D_o_n _F_o_l_l_a_n_d, _N_e_i_l _C_r_o_f_t


 5.3.1  Overview and Rationale

 Information System Management issues are considered in this clause.  The   e
 subject is concerned with the effective management and control of the      e
 complete set of resources that comprise an information system.  The tools  e
 in support of the services required by system managers need to reflect     e
 the portability and interworking attributes of open systems and fit the    e
 Open System Environment Reference Model (Figure 3-3).  It is necessary to  e
 consider a variety of system management support scenarios (central         e
 management, dispersed management, or hybrid), addressing both distributed  e
 systems and standalone systems.  The issues apply to application software  e
 or software components of the application platform.  It is necessary to    e
 support automated management and operation of the IT infrastructure and    e
 address a wide variety of licensing scenarios.                             e


 5.3.2  Scope

 This category includes services and policies that address the
 administration of the overall information system required by any
 organization, including:

     - Information Management

     - Processor Management (e.g., Add new user)

     - Network Management

     - Configuration Management

     - Security Management (e.g., Authentication, Key Management)

     - Accounting Management

     - Performance Management

 Administration services accessible from the API may have Programming
 Language or Language Binding service specifications associated with them.

 These services are defined to provide system and network administrator
 portability.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.3 Information System Management                                     215






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 5.3.3  Reference Model

 The Reference Model for system management is the same as the model shown   e
 in Figure 3-3.  System management impacts all of the APIs and EEIs in the  e
 POSIX Open System Environment Reference Model.                             e


 5.3.4  Service Requirements

 The following services should be provided:                                 e

 5.3.4.1  Processor Configuration Management

 Configuration management consists of four basic functions:
 identification, control, status accounting, and verification.

 Identification involves specifying and identifying all components of an
 IT infrastructure.

 Control implies the ability to agree and ``freeze'' configuration items
 (CIs) and then to make changes only with agreement of the appropriate
 named authorities.  Control is concerned with ensuring that none of the
 CIs shown is altered or replaced and that no CIs are added without
 appropriate authorization.

 Status accounting involves the recording and reporting of all current and
 historical data concerned with each CI.  Status accounting maintains
 records of the current, previous and planned states and attributes of the
 CIs and tracks these states and attributes:  for example, as the status
 of a CI changes from ``development'' through to ``test,'' ``scheduled to
 go live,'' ``live,'' and through to ``archived.''

 Verification consists of a series of reviews and audits to ensure that
 there is conformity between all CIs and the authorized state of CIs as
 recorded in the configuration management database (CMDB).  It is
 concerned with checking that the physical CIs actually match the
 authorized system as described in the CMDB.

 5.3.4.2  Network Configuration Management

 To ensure the viability of network services the configuration of systems
 and services must be controlled and managed.  Effective configuration
 management will produce a minimum risk environment.

 Configuration management procedures must ensure that details are provided
 for network equipment and systems covering:

     - Configuration activities--how to configure the network equipment



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 216                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Security controls

     - Access controls

     - Configuration history log

     - Configuration authority

     - Build details

     - Fall-back and test records

     - Management reporting requirements.

 5.3.4.3  Distributed System Configuration Management

 The services here consist of the following:                                e

     - Authentication services for a distributed system environment

     - Distributed Naming Service Configuration

     - Distributed Time Service Configuration

     - X Window system configuration

     - Window/Session Manager configuration

 5.3.4.4  Software Installation and Distribution

 The main types of software to be installed and distributed are
 application programs developed in-house, bought-in applications, and
 utility software and personal computer software packages.  All software
 needs to be managed effectively from development or purchase through to
 the live environment.  Unless the distribution and implementation process
 can be controlled automatically, or from the center using software tools,
 procedures must be in place to ensure that distributed software arrives
 when expected and is checked for authenticity in whatever way is
 practical, and that the software is brought into use when required.  The
 main procedures involved in software distribution and installation are:

     - System management staff at the center to inform remote staff when    e
       to expect distribution software to arrive.                           e

     - Recipients to report to system management staff when the             e
       distributed software has arrived successfully.                       e

     - System management staff to check that all software is received as    e
       expected at locations.                                               e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.3 Information System Management                                     217






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - System management staff to issue clear instructions about when the   e
       software is to be implemented.                                       e

     - Location staff to report to system management at the center when     e
       the software has been implemented.  The release record on the        e
       Configuration Management Database will state which installations
       are to receive the release.  This database must be updated to
       reflect the receipt and implementation of the release at each site.

 5.3.4.5  License Services

 The terms and conditions relating to the supply of software may place
 legal restrictions on the organization (e.g., no unauthorized copies to
 be made).  It is particularly important therefore that the Configuration
 Management Database is updated with details of who holds copies of
 software items.  This assists the organization in discharging its legal
 obligations and assists auditors in checking for the existence of
 unauthorized copies.

 All authorized copies of licensed or purchased software that are made by   e
 system management staff should be allocated a unique copy number and       e
 recorded in the Configuration Management Database together with where      e
 they are located and who is responsible for them.  Procedural
 restrictions should be introduced to prohibit the unauthorized copying of
 software, and regular software audits should include a check for any
 unauthorized copies.

 5.3.4.6  Print Output and Distribution Services

 Output and distribution packages control output production and
 distribution from the moment the output is planned to the time the user
 receives the print.  The working criteria need to be set up first; e.g.,
 define who receives the report and how much of the report the user gets.

 The main functions are:

     - The report can be limited to parts wanted by the user.

     - Multiple copies of the entire report, or of selected sections can
       be produced.

     - Reports are grouped by recipient within delivery location.

     - Reports for each job are spooled as a group when the job is
       complete.

     - The number of whole reports and individual pages received by each
       user are recorded.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 218                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Report production can be monitored and managed efficiently.

 Output and Distribution packages should include the following:             e

     - Printing and distribution of whole and part reports

     - Status (queued, printing etc) of the report tracked

     - Online viewing of reports

     - Ability to archive report files

     - Ability to support a wide range of printers

     - Costing and charging functionality

     - Security facilities

 By using an output distribution package, the delivery of reports to the
 correct person at the correct location can be ensured.  Paper, time, and
 IT resource are saved as the users receive only the parts of reports that
 they need, and can also view the reports online.  The number of pages
 printed can be controlled.  Reports can be tracked from the time they are
 created to the time they are delivered to the user, allowing good
 security monitoring.

 5.3.4.7  Office Media Management and Backup/Restore

 The main services of magnetic tape and data cartridge management systems   e
 are:

     - Provide automated support for tape housekeeping and maintenance
       including:

        +o Allocating tapes and releasing them for reuse helping

        +o To ensure even patterns of use where appropriate

        +o Constructing and triggering cleaning schedules

        +o Maintaining the security of data

     - Help automate archiving (vault management) for offsite storage

     - Help identify growth requirements

 Vault management is concerned with controlling the movement of tape
 cycles from one storage location to another.  As a tape cycle is used,
 the tape management system automatically logs a different vault


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.3 Information System Management                                     219






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 identifier against each tape.

 A backup strategy is required to control the frequency of backups and the
 way in which they are created; e.g., whole volumes to cartridge or
 individual files to tape.

 The backups and restores of system and application software should be
 separate from the backups and restores of data.  Software and library
 backups should be explicitly scheduled and the complete software item or
 library backed up.  The schedule for backing up files must be fully
 documented, properly maintained and adequately safeguarded as the
 contents of the schedule are required for disaster recovery purposes.

 5.3.4.8  Online Disk Management

 The operation of disk management systems requires that they take account
 of a range of factors such as retention period, recovery, space
 fragmentation, disk overflow, file and record activity levels, and
 channel use.  Some systems merely report against values or thresholds
 set, but increasingly they invoke corrective action.  Typically, the
 corrective action is file and disk reorganization or file and data
 archiving.

 If a disk management system is used, the constant monitoring and
 actioning of requests for disk space can be minimized.  Disk space may be
 collectively pooled and unused space constantly reclaimed.

 5.3.4.9  Job Scheduling

 Scheduling involves the continuous organization of jobs and processes
 into the most efficient sequence, maximizing throughput and utilization
 to meet the targets set in service level agreements (SLA).  Jobs are
 scheduled to ensure:

     - SLAs and user requirements are met; e.g., certain jobs need to be
       run by a certain time

     - Available capacity is used effectively; e.g., the workload run at
       any given time does not exceed the practical capacity.

 The minimum services of a scheduler should include:                        e

     - A high upper limit for the number of relationships allowed between
       jobs

     - The ability to schedule by calendar and criteria

     - Workload balancing support



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 220                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - Levels of security

     - Ability to restart jobs

     - Operator override capability

     - Capability to model future workloads.

 5.3.4.10  User Administration                                              e

 The services here consist of the ability to:                               e

     - Create a new user or group of users                                  e

     - Delete a user or group of users                                      e

     - Allocate system resources to a user or a group of users              e

 5.3.4.11  Accounting

 An effective cost management system should contribute to the development   e
 of a sound investment strategy that recognizes and evaluates the options   e
 and flexibility available from modern technology.  The services here       e
 should provide the ability to:                                             e

     - Establish targets for performance                                    e

     - Measure performance against targets                                  e

     - Measure and prioritize resource usage                                e

     - Monitor assets and maintain records for control purposes             e

     - Apportion costs of IT services to users                              e

     - Report costs to management and users                                 e

 5.3.4.12  Performance Management

 The services here should provide the ability to:                           e

     - Monitor hardware, software, and network performance                  e

     - Monitor workload and throughput                                      e

     - Set and adjust system parameters to tune performance                 e

     - Monitor terminal response time                                       e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.3 Information System Management                                     221






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 5.3.4.13  Capacity Management

 An effective and efficient capacity management function contains at least
 the following elements:

     - Performance management to monitor and optimize the use of current
       systems.

     - A capacity management database that contains current and historic
       data of technical and business related interest.  This database
       forms the basis for the provision of both tactical and strategic
       reports on performance and capacity.

     - Workload management to identify and understand the applications
       that make use of the system.  The understanding of workloads has
       both a technical and business related nature.  This involves
       application sizing to accurately predict the performance and
       required capacity of new applications.

     - Capacity planning to accurately plan the required hardware resource
       and associated cost for the future and to predict the effect on
       performance and capacity of both tactical and strategic plans.

 5.3.4.14  Fault Management                                                 e

 These services allow the system to react to the loss or incorrect
 operation of system components at various levels (hardware, logical,
 services, etc.).  The classical model of fault tolerance has a three-step
 approach.  The three steps are fault detection, fault isolation, and
 fault recovery.  Typically implementations divide these steps into
 multiple steps or integrate them into one or two steps.  Additionally,
 fault diagnosis services support the other steps in the treatment of a
 fault.

 Various fault tolerance strategies, such as checkpointing and voting, are
 implemented as a collection of services comprising one or more of the
 steps in the fault tolerance classical model.  For example, services
 involved in implementing a three-node voting scheme will include a vote
 comparator service (fault detection), vote analyzer service (fault
 isolation/fault diagnosis), a service to pass the majority ``answer''
 through (fault recovery) as well as a service to disable the faulty
 resource and reconfigure the voters (fault recovery/reconfiguration).

 _F_a_u_l_t__D_e_t_e_c_t_i_o_n

 Fault detection services are concerned with determining when a fault has
 occurred in the system.  Fault detection services are both passive and
 active.  Active services are those that attempt to determine the status
 of various system components by testing those components.  Passive


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 222                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 services, on the other hand, try to ascertain system components by
 passively gathering information and watching the behavior of the system.

 _F_a_u_l_t__I_s_o_l_a_t_i_o_n

 Fault isolation services attempt to determine the component at fault and
 segregate the faulty component from the rest of the system.  Services may
 be shared between the fault detection and isolation service library in
 that they perform both functions.

 _F_a_u_l_t__R_e_c_o_v_e_r_y

 Fault recovery services attempt to bring the system into a consistent
 state.  These services may be very interrelated to the scheduling
 services, network services, and data base services, depending on the
 recovery scheme used.

 Redundancy of resources is many times needed to support fault recovery.
 Resources may include data, process, processor, disk drive, etc.

 As parts of the system fail, it may no longer be possible to satisfy all
 the requirements of the application.  Services to support graceful
 degradation may be used to ensure that critical activities do not fail.

 _F_a_u_l_t__D_i_a_g_n_o_s_i_s

 These services deal with the system's ability to analyze the attributes
 of a system fault and determine its cause.  These services tend to be
 very interrelated with fault detection and fault isolation services.

 _F_a_u_l_t__A_v_o_i_d_a_n_c_e

 These services involve the avoidance of faults before a failure in the
 system component occurs.  If a system can detect that the operation of a
 component is approaching the edge of its operational range, a standby or
 backup component could be phased in to replace it.  Another form of fault
 avoidance is logging of shocks, temperature extremes, etc., so that it
 can be predicted that a component will not meet its original expected
 service life.

 _S_o_f_t_w_a_r_e__S_a_f_e_t_y

 These services involve the system's ability to keep application software
 from causing harm to the system's software, hardware, or user.  For
 instance, a process may attempt to write into another process's memory
 space without permission.

 A good example of a reliability method that may provide software safety
 is a bounds checker.  The checker compares an answer supplied against the


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.3 Information System Management                                     223






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 bounds.  If it is not within the bounds, the bounds checker will not
 allow the answer to propagate, possibly causing damage to the system's
 integrity.  Additionally, it may send a fault message (or security
 violation information, depending on the type of answers expected) to the
 proper service.

 To enhance software safety, other services and processes should be only
 given the resources necessary to complete their job.

 _S_t_a_t_u_s__o_f__S_y_s_t_e_m__C_o_m_p_o_n_e_n_t_s

 These services involve the obtrusive and nonobtrusive diagnosis of the
 state of system components.  For further explanation of these services,
 see Fault Detection and Fault Diagnosis services.  These services may
 additionally need to record and/or display information concerning
 performance, configuration, and general system information.

 _R_e_c_o_n_f_i_g_u_r_a_t_i_o_n

 These services allow the system to reconfigure its view of the world.
 This services allow the system to substitute different resources to
 perform system functions such as substituting a new physical I/O channel
 to support a logical channel.  These services are part of the API but
 their use may be restricted to specially authorized programs such as
 those used by the target system operator.

 _M_a_i_n_t_a_i_n_a_b_i_l_i_t_y

 Maintainability services provide support for the maintenance of a system.
 A major component of that support is the collection and logging of
 information about the operation of the system.  Typical information to be
 logged is:

     - Software and hardware errors during operation

     - Processes that failed or almost failed to meet scheduled deadlines

     - Performance metrics for system tuning

     - Times when the system operated in extreme environmental conditions

     - Errors reported during startup self-testing

     - Attempts to violate rules of the system's security policy.







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 224                                   5 POSIX OSE Cross-Category Services






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 5.3.4.15  Security Management

     - Configuration of appropriate ACLs for System, User Interface,
       Storage, Network, and application software services.


 5.3.5  Standards, Specifications, and Gaps

 There are a number of international and national initiatives to develop    e
 standards for system management.                                           e

 _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s:  _T_h_i_s _s_u_b_c_l_a_u_s_e _w_i_l_l _b_e _e_x_p_a_n_d_e_d _i_n _a _l_a_t_e_r _d_r_a_f_t.      e


 5.3.6  OSE Cross-Category Services

     - Security for remote print jobs


 5.3.7  Related Standards

 None.                                                                      e





























              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 5.3 Information System Management                                     225








































































                                                               P1003.0/D14








                            Section 6: Profiles



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _F_r_i_t_z _S_c_h_u_l_z

 This section targets those who want to know more about what profiles are
 and those who are in the process of developing their own profiles.  The
 latter group consists of those developing formal ``Standardized
 Profiles'' and those developing less formal profiles for their industry
 group (e.g., a banking trade association) or their own company or
 enterprise for procurement or strategic planning purposes.

 Those not involved in the development of profiles should read 6.2.  Parts
 of 6.3 also may be useful, especially the earlier subclauses that give
 definitions of terms and explain concepts more precisely.

 Developers of profiles that are not formal POSIX Standardized Profiles
 (POSIX SPs) should read all of Section 6.

 Developers of profiles that are formal POSIX SPs should read all of
 Section 6 and Annex A.



 6.1  Scope

 The information presented here about profiles is limited in scope to
 assist those needing to understand profile concepts as they apply to the
 POSIX Open System Environment.  Covered are profiles constructed from
 standards (and profiles) listed within this guide (that, by design, are
 consistent with POSIX.1).

 The goal is to create a common approach and documentation scope and style
 for POSIX-oriented profiles.  Annex A goes further by giving specific
 guidance to developers of formal POSIX SPs.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 6.1 Scope                                                             227






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 6.2  Profile Concepts

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _B_o_b _G_a_m_b_r_e_l

 _I_n_t_r_o_d_u_c_t_i_o_n

 This guide is designed to assist in the selection of standards in the
 procurement process or as a target application environment.  Profiles
 also assist in the selection of standards.  A profile is a suite of base
 standards with specified options.  Profiles can be created by software
 developers to describe the environment they target or by buyers to
 identify their purchasing objectives.

 _B_a_s_i_c__T_e_r_m_i_n_o_l_o_g_y

                                                                            e

 There are two general classes of standards documents:

     - Base standards

     - Profiles, including application environment profiles (AEP),          e
       standardized profiles, and POSIX standardized profiles               e

 See 2.2.2 for format definitions of these terms.  As used in this guide,   e
 base standards specify functionality, syntax, protocols, data formats,     e
 etc., in detail, while profiles do not.  Instead, profiles (sometimes      e
 called ``functional standards'') identify which base standards are         e
 applicable.  Since base standards often consist of a base or mandatory     e
 part and a number of selectable optional parts and values, profiles may
 also (or may not) choose, for each base standard, specific options or
 values.  A profile may also identify other profiles, allowing the
 construction of ``larger'' profiles based on both base standards and
 other ``smaller'' profiles.

 NOTE:  In the context of internationalization, the term ``national         e
 profile'' is frequently used and will be found, for example, in            e
 POSIX.1 {2} and POSIX.2.  Its meaning is consistent with the definitions
 in 2.2.2, but in many cases such profiles reflect national cultural
 conventions.  For example, Denmark and Japan both have specified a
 national character profile.


 6.2.1  Relationships Between This Guide and Profiles

 Key to the understanding of profiles is a discussion of the relationships
 that exist among profiles, this guide, and the base standards.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 228                                                            6 Profiles






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 There exist many thousands of base standards, each addressing a
 particular, usually narrowly scoped, area of application portability or
 interoperability.  Many of the base standards, developed over the years,
 are simultaneously narrow in scope (for example, a C binding of SQL), but
 broadly applicable (for example, applicable to operating systems that      e
 comply with POSIX specifications and those that do not.)                   e

 The base standards listed in 1.2 form the basis of the POSIX Open System
 Environment.  The list is comprehensive, in that its coverage is broad
 enough to cover most modern day application development, and the base
 standards selected have been determined to be consistent with
 POSIX.1 {2}.

 While this guide does not list all base standards, it is still a large
 list, and in fact the list contains base standards that might not be
 consistent with each other (choose any two standards from the POSIX OSE
 and they might not be consistent with each other.)  The process of
 profile writing addresses this.

 The profile writer reduces even further the list of base standards to
 just the (relatively) few that are needed to provide portability and
 interoperability in a given functional area.  In the process, the profile
 writer grapples with the coherence of the selected base standards by
 choosing only those that will work together to get the particular job
 done.  Profile writers should also deal with _h_a_r_m_o_n_i_z_a_t_i_o_n,3) which means
 making the profiles consistent with each other where they overlap.  This
 can often be done among profiles even where the functional areas served
 differ greatly.  Procurements specifying two profiles that have been
 harmonized by their authors have the benefit of knowing that the two will
 not conflict with each other.

 By specifying compliance to a particular profile in a procurement, a
 consumer easily references a set of multiple base standards that have
 been determined to:  serve a particular purpose and work together.         e

 The benefits and relationships do not end here, however.  Since profiles
 can be constructed to reference profiles as well as base standards,
 future profile writing will be even easier.
 NOTE:  An analogy is in the construction of electronic equipment such as
 computers.  The basic building blocks are ``components,'' such as memory
 chips and capacitors, which can be fabricated into larger building blocks
 such as printed circuit boards, which can be fabricated (with other


 __________
  3) This should not be confused with _i_n_t_e_r_n_a_t_i_o_n_a_l _h_a_r_m_o_n_i_z_a_t_i_o_n, which    e
     refers to a specific process that must be followed in the approval     e
     process for International Standardized Profiles (ISPs).                e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 6.2 Profile Concepts                                                  229






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 components or printed circuit boards) into larger building blocks, such
 as standalone computers, which can be fabricated into larger building
 blocks such as department wide networks of computers, etc.  Likewise, a
 few base standards (the basic building blocks), can be gathered together
 into ``component'' profiles, which can then be gathered together (with
 other base standards or component profiles) into larger ``platform''
 profiles, which can be gathered together into larger ``application area''
 profiles.  (See 6.3.3.5.)

 The development of profiles from the primary building blocks (base
 standards) results in larger building blocks (profiles) that can then be
 incorporated into future profiles and also into future versions of this
 guide.

 _T_h_e__I_m_p_o_r_t_a_n_c_e__O_f__P_r_o_f_i_l_e_s

 Profiles are important for a number of reasons:

     - Profiles select one or more base standards or profiles and specify
       options and parameters within these.  This provides a clear
       statement of specifications that describe the standards for the
       target functional objective(s).

     - Profiles include information about the relationship between the
       standards included (i.e., coherency is an objective).

     - Profiles are a clear method of communication about the specific
       standards needed for an application domain and can be used in
       procurement, in conformance testing, and as a target for
       applications development.



 6.3  Guidance to Profile Writers

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _B_o_b _G_a_m_b_r_e_l

 This clause expands the concept of profiling in the manner needed by
 profile writers and provides detailed guidance to those writers.  It
 includes a description of the basis for this guidance, expands on the
 purposes served by profiles, and finishes with more detailed guidance
 specifically aimed at those writing profiles.

 Using this guide as a basis, profile writers can develop their own
 informal profiles, suited to their own needs, or formal standards bodies
 can develop formal, balloted profiles.  This clause details the
 requirements that should be met by developers of profiles whether they
 are POSIX SPs, standardized profiles, or less formal profiles.
 Standardized profiles are formal profiles that meet the requirements of a


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 230                                                            6 Profiles






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 sponsoring standards body.  Standardized profiles that also meet the
 requirements for POSIX-based profiles (rules established by IEEE) are
 called POSIX standardized profiles (POSIX SPs.)  For more information
 about writing POSIX SPs, see Annex A.

 _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s:  _A_n_n_e_x _A _h_a_s _i_m_p_o_r_t_a_n_t _i_n_f_o_r_m_a_t_i_o_n _i_n _r_e_l_a_t_i_o_n _t_o _t_h_i_s
 _s_e_c_t_i_o_n _t_h_a_t _s_h_o_u_l_d _b_e _r_e_v_i_e_w_e_d.


 6.3.1  Basis for This Guidance

 Many of the ideas and concepts for profiling described in this section
 derive from the work of ISO/IEC JTC 1 SGFS as documented in ISO/IEC TR
 10000-1.  Some items specified in that document that are not covered here
 include:

     - International standardization considerations

     - Conformance issues

     - Processes and procedures

     - Maintenance

     - Taxonomy

 Additionally, some consideration was given in this guidance above and
 beyond that given in ISO/IEC TR 10000:

     - Standardized profiles and POSIX standardized profiles as a
       conceptual extension to International Standardized Profiles (ISP).

     - IEEE basis, not ISO basis, for formatting rules; see Annex A.

 Writers of profiles following the guidance of this clause should refer to
 Annex A if they intend to propose IEEE acceptance as a POSIX SP and to
 ISO/IEC TR 10000 if they intend to propose acceptance as an ISP.


 6.3.2  Purpose of Profiles

 Profiles define combinations of base standards and profiles for the
 purpose of:

     - Identifying the base standards, together with appropriate classes,
       subsets, options, and parameters, that are necessary to accomplish
       identified functions for purposes such as interoperability and
       portability.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 6.3 Guidance to Profile Writers                                       231






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Providing a system of referencing the various uses of base
       standards that is meaningful to both users and suppliers

     - Enhancing the availability for procurement of consistent
       implementations of functionally defined groups of base standards
       that are expected to be the major components of real application
       systems

     - Promoting uniformity in the development of conformance tests for
       systems that implement the functions associated with the profiles


 6.3.3  Detailed Guidance to Profile Writers

 6.3.3.1  The Relationship to Base Standards

 Base standards specify procedures and formats that facilitate application
 portability and interoperability.  They provide options, anticipating the
 needs of a variety of applications and taking into account different
 capabilities of real systems and networks.

 Profiles further promote portability and interoperability by defining how
 to use a combination of base standards for a given function or
 application area.  Profiles, by definition, do not define new application
 interfaces.

 In addition to the selection of base standards, a choice may be made of
 permitted options for each base standard and of suitable values for
 parameters left unspecified in the base standard.

 Profiles should not contradict base standards, but should make specific
 choices where options and ranges of values are available.  Profiles must
 include all of the items made ``mandatory'' by the standard.  The choice
 of the base standard options should be restricted so as to maximize the
 probability of interworking between systems implementing different
 selections of such profile options, consistent with achieving the
 objectives of the profile.

 A profile makes explicit the relationships between a set of base
 standards used together (relationships that are implicit in the
 definitions of the Base Documents themselves) and may also specify
 particular details of each base standard being used.

 A profile may contain conformance requirements that are more specific and
 limited in scope than those of the base standards to which it refers.
 While the capabilities and behavior specified in a profile will always be
 valid in terms of the Base Documents, a profile may exclude some valid
 optional capabilities and optional behavior permitted in those base
 standards.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 232                                                            6 Profiles






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 Thus, conformance to a profile implies, by definition, conformance to the
 set of base standards that it references.  However, conformance to that
 set of Base Documents does not necessarily imply conformance to the
 profile.

 6.3.3.2  Main Elements of a Profile Definition Document

 The definition of a profile should comprise the following elements:

     - A concise definition of the scope of the function for which the
       profile is created and of its purpose

     - Reference to a set of base standards and other profiles, including
       precise identification of the actual texts of the base standards
       and profiles being used and of any approved amendments and
       technical errata, conformance to which is identified as potentially
       having an impact on achieving portability and interoperation using
       the profile

     - Specifications of the application of each referenced base standard
       and profile, covering recommendations on the choice of classes or
       subsets and on the selection of options, ranges of parameter
       values, etc.

     - A statement defining the requirements to be observed by systems
       claiming conformance to this profile, including any remaining
       permitted options of the referenced base standards and profiles,
       which thus become options of this profile

 Systems that interoperate can perform different but complementary roles
 (e.g., an initiator-responder or a master-slave relationship).  In such a
 situation the profile should identify the separate roles that may be
 adopted by a system, and these should be stated as either mandatory
 requirements or options of the profile, as appropriate.

 6.3.3.3  Profile Objectives

 _C_o_m_p_l_e_t_e_n_e_s_s

 A profile should be complete with respect to its functionality
 objectives.  This may well be an iterative process, since the
 understanding of the requirements and standards will evolve.
 Completeness means that all areas where standards should be applied have
 been identified and the requirements defined.  Where standards exist,
 they have been included, and the options within those standards have been
 addressed.  Where standards do not exist, but are needed, this has been
 documented in the profile.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 6.3 Guidance to Profile Writers                                       233






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 It may be appropriate to document (probably in a nonnormative appendix)
 specifications and alternatives available in areas where standards have
 not been defined.  The meaning of this concept will be relative to the
 forum for acceptance of the profile.  If the profile is targeted at ISO
 acceptance, then ISO DIS and IS standards should be the reference point,
 where as a US Government profile might be focused on FIPS and ANSI
 standards.  Within private industry, consortium and even vendor specific
 specifications could be incorporated, keeping these as examples and not
 explicit requirements, which will simplify harmonization with formal
 standards as they emerge.  Where standardized profiles are being
 developed and gaps are identified, the profile writer should identify the
 requirements that are not satisfied by a standard.  If there is a
 preliminary specification available that addresses many of the
 requirements, that specification should be referred to informatively.

 _C_l_e_a_r__C_o_m_m_u_n_i_c_a_t_i_o_n_s

 A key objective for the profile is clear communications between the
 affected parties.  Users, software developers, and platform suppliers all
 need to have the same terms and specifications.  The application software
 developers and system vendors need a common set of specifications to
 target for their development efforts.

 _H_a_r_m_o_n_i_z_a_t_i_o_n

 Harmonization4) means making the profiles consistent with each other
 where they overlap.  This can often be done among profiles even where the
 functional areas served differ greatly.  This assures that the maximum
 practical agreement exists between different profiles, maximizing the
 implementations of that common ground.

 _V_a_l_i_d_a_t_i_o_n

 A profile addresses validation in two different ways.

 Firstly, by selecting options and parameters within the profile,
 validation is potentially made simpler.

 Secondly, by including more than one base standard, validation
 potentially becomes more difficult.  Now validation extends beyond just
 insuring a single standard is being complied with into the area of
 insuring that the interactions between and among multiple base standards
 is also being complied with.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 234                                                            6 Profiles






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _C_o_h_e_r_e_n_c_e

 The simple selection of a group of standards does not assure that they
 will work together on a platform in a predictable way.  A profile should
 contain a matrix of all standard components compared to each other and
 state what relationship exists between them.  A profile may be coherent
 if it states that between two standards no relationship needs to exist,
 that none shall exist, or that a specified relation shall exist.  Not to
 speak to an intersection in the matrix would indicate that the issue of
 coherence has not been addressed.

 _G_a_p__I_d_e_n_t_i_f_i_c_a_t_i_o_n

 In the process of developing profiles, there may be gaps in coverage by
 standards that become apparent.  These may exist in terms of the
 characteristics available with one standard that need to be made
 available from another, or missing standards, or additional functionality
 that is needed for a specific applications activity.  So, an additional
 objective for a profile effort is to document the requirements for such
 additional work and forward it to the appropriate standards effort.
 Profile groups in industry should consider providing expertise to the
 associated standards groups to assure that the resulting standards meet
 the needs of that applications area.

 6.3.3.4  Methods for Developing Profiles                                   e

 _T_o _B_e _D_e_t_e_r_m_i_n_e_d.                                                          e

 6.3.3.5  Types of Profiles

 Three different types of profiles have been, or are being, defined by the
 procedures described above:

     - Component Profiles

     - Application Area Profiles

     - Platform Profiles

 A Component profile is mostly a subset of a single standard.  The profile
 developers specify mandatory options for a specific domain, options that
 are not desirable for that domain, gaps in that parent standard, and, if
 necessary, specifications to fill that gap.  Examples of such profiles
 are MAP, TOP, and GOSIP profiles and possibly the POSIX.13 embedded







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 6.3 Guidance to Profile Writers                                       235






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 realtime POSIX profile if it continues to be based exclusively on
 functions chosen from the POSIX.4 realtime standard.

 An Application Area Profile is created from multiple standards that
 specify multiple, diverse types of functionality needed for a particular
 application area (e.g., database, networking, graphics, operating
 system).  The application area profile developers specify all the diverse
 standards necessary for the application area in question.  Within each
 standard, they identify mandatory options, functions and options that are
 not needed, gaps in the standards, and, if necessary, specifications to
 fill the gaps.  Examples of application area profiles are the POSIX.10
 supercomputing and POSIX.11 transaction processing profiles.

 A Platform Profile focuses on the functionality and interfaces needed for
 a particular type of platform.  The platforms could be traditional
 platforms (such as time sharing systems) or relatively new or emerging
 platforms (e.g., workstations, personal computers, or symmetric
 multiprocessing systems).  A platform profile could be created from one
 or multiple diverse standards.  As with other types of profiles, the
 profile developers have to specify the standards, options, standards
 gaps, and if necessary, specifications to fill the gaps.  Examples of
 platform profiles are the POSIX.18 Platform Profile for Traditional
 Multiuser UNIX systems and the POSIX.14 Multiprocessing profile.

 All three types of profiles can be seen in the next section.


























              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 236                                                            6 Profiles






                                                               P1003.0/D14








                   Section 7: POSIX SP Profiling Efforts



 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _W_e_n_d_y _R_a_u_c_h



 7.1  Introduction

 This section maintains the list of currently known POSIX Standardized
 Profiles (POSIX SPs).  This list is a factual record of which POSIX SPs
 exist, or are in preparation, together with a summary description of the
 scope, scenario, and model for each profile.  These POSIX SPs might be
 useful as building blocks for other profiles.


 7.1.1  Approved POSIX Standardized Profiles

 There are currently no approved POSIX SPs.


 7.1.2  POSIX Standardized Profiles In-Progress

 The current efforts to develop POSIX SPs are summarized in Table 7-1.      e



 7.2  General Purpose POSIX SPs


 7.2.1  POSIX Platform Environment Profile                                  e












              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 7.2 General Purpose POSIX SPs                                         237






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS


                    Table 7-1  -  POSIX SPs In Progress
 __________________________________________________________________________________________________________________________________________________
    Project
     Name      Taxonomy            Profile Name                     Profile Type
 _____________________________________________________________________________________

 IEEE P1003.10          Supercomputing                        Application area profilee
 IEEE P1003.11          Transaction Processing                Application area profilee
 IEEE P1003.13          Realtime, Multipurpose Systems        Application area profilee
 IEEE P1003.13          Realtime Embedded Control System      Application area profilee
 IEEE P1003.13          Realtime Intermediate                 Application area profilee
 IEEE P1003.14          Multiprocessing Application Support   Platform profile
 IEEE P1003.18 USI-P001 POSIX Platform Environment Profile    Platform profile
 NOTES:

     (1)  At this time it is not known whether the three realtime profiles
          will be contained within a single multipart POSIX SP, or
          separate single-part POSIX SPs.

     (2)  While the issue of a taxonomy for POSIX SPs has not been
          decided, a placeholder has been provided and a proposed
          taxonomical name for one profile has been listed.

 __________________________________________________________________________________________________________________________________________________


 7.2.1.1  Rationale and Overview

 The POSIX Platform Environment Profile, IEEE POSIX.18, is a platform       e
 profile based on POSIX.1 {2} and related standards.  It defines the
 functionality and standards needed for a system that is as similar as
 possible to the traditional UNIX operating system's interactive,
 multiuser development and run-time environment.

 The platform profile is valuable for many users, vendors, programmers,     e
 and procurement officers who do not have the time or desire to analyze
 and specify all the individual interfaces for a system they need.  The     e
 platform profile obviates this analysis by enabling the users to point to  e
 a single document that specifies exactly what they should order to obtain
 a system that looks like traditional UNIX systems, except that the POSIX   e
 platform profile will be totally based on formal standards.                e









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 238                                          7 POSIX SP Profiling Efforts






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 7.2.1.2  Content of the Platform Environment Profile

 The POSIX Platform Environment Profile consists of:

     - ISO/IEC 9945-1, with a selection of options and definitions of       e
       parameters;                                                          e

     - All of the POSIX.2 (Shell and Utilities) and, optionally, POSIX.2a   e
       (User Portability Extension); and                                    e

     - At least one of the following languages:  ISO C, Ada, or FORTRAN.    e

 To reflect the goals and intent of the POSIX.18 working group, the POSIX   e
 platform profile document also commits to specifying additional            e
 specifications in the future, when those specifications are completed and
 approved as standards.  These specifications include system
 administration, secure/trusted systems extensions, realtime facilities,
 verification testing facilities, Ada and FORTRAN language bindings,
 graphical user interfaces, and network interface facilities.

 The POSIX platform profile is expected to be the pioneer Application       e
 Environment Profile submitted to ISO for international approval.  The
 concept of Application Environment Profiles and Platform Profiles is new.
 How ISO handles the international standardization of the POSIX platform    e
 profile, and the profile issues resolved, will likely set a precedent      e
 followed in the development of other profile standards.


 7.2.2  Multiprocessing Systems Platform Profiles

 7.2.2.1  Rationale and Overview

 The POSIX Multiprocessing Systems Profile (IEEE POSIX.14) is a platform
 profile.  Like the POSIX PEP (POSIX.18), the Multiprocessing Systems
 profile defines the functionality, standards, and options within
 standards that are needed for development and execution on a
 multiprocessing platform.

 The Multiprocessing Systems profile is intended for use by multiprocessor
 vendors, application developers, users, and system administrators.  It is
 important because it is designed to support portability of
 multiprocessing applications, as well as users and system administrators
 in multiprocessing environments.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 7.2 General Purpose POSIX SPs                                         239






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 The Multiprocessing Systems Profile has two major goals.  The first one
 is to make POSIX safe for multiprocessing.  This goal requires the
 POSIX.14 working group to identify and address the caveats, problems, and
 failings of POSIX base standards for multiprocessing platforms.  Examples
 of these failings range from reentrant-function problems to potential
 problems with threads.

 The second goal is to make POSIX useful for multiprocessing.  This goal
 requires the POSIX.14 working group to ensure that POSIX supports the
 functionality needed by multiprocessing platforms.  An example of this is
 ensuring that POSIX has capabilities to allow vendors to parallelize
 software functions.  In the absence of parallelizing standards, the
 details of what happens when the same software functions are used on
 different multiprocessor system vary.

 7.2.2.2  Content of the Multiprocessing Systems Profile

 The Multiprocessing Systems platform profile identifies standards,
 options, and gaps in the standards relevant to multiprocessing.  It also
 identifies additional requirements not satisfied by existing standards
 and, in an informative annex, suggests interfaces to extended services
 that can satisfy some of these requirements.  In addition, the POSIX.14
 Multiprocessing Systems Group will propose changes and amendments to a
 variety of relevant standards in order to encourage the specifiers of
 these standards to add functions and options that accommodate
 multiprocessing requirements.

 Standards particularly relevant to the Multiprocessing System Profile
 include the POSIX Pthreads extension (IEEE POSIX.4a), the supercomputing
 batch scheduling standard (IEEE POSIX.15), and the supercomputing
 proposed checkpoint and restart facilities (IEEE POSIX.10).  Since
 checkpoint and restart facilities will be added to the POSIX.1 {2}
 standard, POSIX.1 {2} is also of concern to the Multiprocessing Profile.

 The Multiprocessing Systems profile will specify both general-purpose-
 computing and multiprocessor-specific standards.  General-purpose
 standards planned or under consideration for the Multiprocessing Systems
 profile include:

     - The IEEE POSIX.1 core POSIX system, POSIX.2 POSIX Shell and
       Utilities, and POSIX.2a User Portability Extension;

     - The IEEE POSIX.4 realtime extension;








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 240                                          7 POSIX SP Profiling Efforts






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - The IEEE POSIX.4a:  POSIX Pthreads extension;

     - The IEEE POSIX.6 POSIX security standard and POSIX.7 system
       administration standard;

     - The Ada language bindings (IEEE POSIX.5) and FORTRAN language
       bindings (IEEE POSIX.9) to POSIX;

     - The IEEE POSIX.10 Supercomputing Profile, POSIX.11 Transaction
       Processing Profile, and POSIX.13 Realtime Applications Profiles.

 As other standards emerge, they too will be incorporated in the
 Multiprocessing Systems profile.  An annex of this document will deal
 with, and list, relevant emerging standards to provide an idea of the
 Multiprocessing Systems profile's direction.

 Multiprocessing-specific requirements identified by the POSIX.14
 Multiprocessing working group include:

     - System administration tools for multiprocessors;

     - Parallelizing compilers;

     - Explicit parallelism;

     - Threads;

     - Thread-safe libraries;

     - Message-passing IPC;

     - Parallel utilities (e.g., find, grep, make, etc.);

     - Scheduler controls;

     - Processor allocation:  mandatory/advisory;

     - Processor binding;

     - Degree of symmetry:  I/O, computation, memory.

 Standards will be needed for many of these requirements.  Many of these
 requirements will, therefore, become the subject of a POSIX.14 working
 group proposal for a new standardized function or an option in other







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 7.2 General Purpose POSIX SPs                                         241






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 standards.


 7.2.3  Supercomputing

 7.2.3.1  Rationale and Overview

 The Supercomputing Application Environment Profile (IEEE POSIX.10) is a
 profile designed to support application and programmer portability in
 POSIX-based supercomputer environments.  The profile's goal is to allow
 supercomputer application code to be ported to other sites, reduce the
 learning curve of users, and encourage production of timely third-party
 applications.

 The need exists for such a profile because of the differences between
 supercomputing environments and traditional application environments.
 One difference is that supercomputing jobs are computationally intensive,
 very long running, and very demanding of resources.  Another is that the
 cost of the supercomputer CPU and many of its peripheral resources is
 extremely high.

 Ordinary POSIX standards are not applicable in their entirety to
 supercomputer environments because the traditional UNIX-based POSIX
 functions are not adequate to meaningfully manage the use of, and
 accounting for, a supercomputer or its resources.  Furthermore,
 supercomputers need much better tape handling, multiprocessing, and other
 capabilities than POSIX or UNIX specifications presently support.

 7.2.3.2  Content of the Supercomputing Profile

 The Supercomputing Application Environment Profile identifies POSIX base
 standards and other relevant standards that support supercomputing
 requirements.  Where none exist, the POSIX.10 working group will define
 the functionality itself, or instigate the formation of a new group to
 define it.  In addition, the POSIX.10 working group is taking some of the
 traditional modifications built to allow UNIX systems to run on
 supercomputers, and making those modifications both consistent across
 supercomputers and portable to users, system administrators, and
 applications.

 Base computing standards specified by the supercomputing profile (or
 planned for specification when the standards are completed) include:









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 242                                          7 POSIX SP Profiling Efforts






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - The IEEE POSIX.1 {2} core POSIX system, POSIX.2 POSIX Shell and
       Tools, and POSIX.2a User Portability Extensions (and the
       corresponding FIPS standards);

     - The IEEE POSIX.4 realtime work (particularly the use of its
       asynchronous I/O facility);

     - The IEEE POSIX.6 POSIX security standard and POSIX.7 system
       administration standard;

     - Several graphics standards, including ISO GKS, PHIGS, and CGM, ANSI
       IGES, and the X Consortium's PEX.

     - X3H2.6 (also called X11) for windowing;

     - Several programming languages, including ISO, ANSI, and the NIST's
       FIPS for C, FORTRAN-77, Pascal, Ada, Common LISP, and COBOL.

     - TCP/IP protocol stacks and network applications (e.g., file
       transfer and messaging) now and OSI in the long-term;

     - The IEEE POSIX.8 Transparent File Access standard for distributed
       file management;

     - The X3T5.5 Remote Procedure Call (RPC).

 The nonstandardized and nonavailable supercomputing functions identified
 in the POSIX.10 profile include:

     - Batch system scheduling, administration, and network definition;

     - Checkpoint recovery;

     - A resource manager;

     - A better tape management facility;

     - Better mass storage/archiving facilities.

 There are no existing standards for batch scheduling and administration
 facilities.  Batch scheduling and administration extensions to POSIX base
 standards are currently being defined by the IEEE POSIX.15 working group-
 --a group spawned by the Supercomputing profile working group.








              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 7.2 General Purpose POSIX SPs                                         243






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 To meet recovery and archiving requirements, the POSIX.10 working group
 defined system interfaces for functions that perform ``checkpoint,''
 ``restart,'' and better magnetic tape handling (e.g., to rewind a tape
 under program control).  These interfaces have been submitted to the
 POSIX.1 working group for inclusion in the next POSIX.1 {2} revision.


 7.2.4  Transaction Processing

 7.2.4.1  Rationale and Overview

 The Transaction Processing Application Environment Profile (IEEE 1003.11)
 is intended to support the development of portable online transaction
 processing (OLTP) applications in POSIX environments.  This profile is
 targeted at application developers and open system services suppliers.
 It is important because transaction processing is a major area of
 business for most large computer vendors and it plays a major role in the
 daily operations of most users.  There are currently no existing POSIX
 functions that specifically address OLTP needs.

 7.2.4.2  Content of the Transaction Processing Profile

 The Transaction Processing profile's goal is to identify the interfaces
 and standards relevant to OLTP, and optional functions in existing
 standards that must be made mandatory for OLTP applications.  The profile
 will specify general-purpose standards, as well as standards unique to
 OLTP.

 The Transaction Processing Profile's specifications include or plan the
 following generic and transaction processing-specific standards:

     - The ISO/IEC 9945-1: 1990 (POSIX 1003.1) core POSIX system
       interfaces (including required options, minimum values for certain
       variables, and particular environment variables needed for OLTP
       applications);

     - The IEEE 1003.2 Shell and Utilities' software development utilities
       option, C language development utilities option, and C language
       bindings option;

     - The IEEE 1003.2 getconf utility;

     - The realtime files and asynchronous input and output features from
       the IEEE 1003.4 Realtime POSIX Extensions;







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 244                                          7 POSIX SP Profiling Efforts






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - The IEEE 1003.6 POSIX security standard;

     - The ISO/IEC, ANSI, and FIPS C and COBOL programming languages;

     - TCP/IP networking in the short term and OSI in the long-term;

     - The X3T5.5 Remote Procedure Call (RPC)

     - The ISO SQL database language;

     - The ISO Distributed Transaction Processing 10026.1, .2, and .3 for
       communication of transaction information.

 The Transaction Processing profile also identifies extensions needed to
 existing standards to support distributed transaction processing.
 Important extensions that need to be defined include those related to the
 two-phase commit, as well as others related to making RPCs robust.

 The P1003.11 working group is working with the ISO RPC Group to add
 transaction semantics to the Networking working group's RPC
 specifications.  These extensions will be incorporated in the Transaction
 Processing profile.  Plans are also for the 1003.11 profile to draw on
 the transaction processing work being produced by the X/Open consortium,
 particularly on the XA interfaces (the interface between a Transaction
 Manager and a Resource Manager).


 7.2.5  Realtime Application Profiles

 7.2.5.1  Rationale and Overview

 Different types of realtime applications have different characteristics
 and diverse requirements.  For example, embedded systems generally do not
 need the full functionality of an operating system, nor do they require
 all the IEEE POSIX.4 realtime extensions.  Compliance with the entire
 realtime standard and/or POSIX operating system interfaces could reduce
 the embedded system's responsiveness and increase the amount of memory
 needed for systems that need to be embedded in limited space.  High-end
 realtime systems, on the other hand, have softer realtime requirements.
 However, they need the full operating system and realtime functionality.

 Therefore, the POSIX.13 working group was formed to define profiles for
 various types of realtime applications.  The realtime profiles defined
 will determine which interfaces must be implemented for a given type of







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 7.2 General Purpose POSIX SPs                                         245






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 realtime system to claim conformance to the realtime standard.

 7.2.5.2  Targeted Realtime Application Profiles                            e

 The POSIX.13 working group is defining profiles to address several types   e
 of realtime applications.  These include:                                  e

     - Low-end, embedded systems (often known as ``hard'' realtime
       systems);

     - Mid-range realtime systems with medium-level critical realtime
       constraints;

     - High-end realtime systems.

 7.2.5.2.1  Embedded Realtime Systems                                       e

 Embedded realtime systems are typically standalone systems used for robot
 controllers, automated systems controllers, instrumentation, high-speed
 data acquisition, satellite subsystem control, flight control, some        e
 process control, and some testing.  Time-critical responsiveness is a key  e
 requirement of embedded systems.  In the absence of a standard, the
 realtime functionality required for embedded systems is generally
 provided by a proprietary realtime kernel or a simple home-grown monitor
 using memory mapped I/O.

 Since low-end embedded systems need only minimal functionality, the
 POSIX.13 working group will select a relatively small number of POSIX.4
 and POSIX.1 {2} functions that will be required for portable realtime
 embedded systems.  These functions will be selected for several types of   e
 embedded applications.                                                     e

 One type of embedded application is a minimal system, usually buried       e
 deeply in the overall system electronics.  Such minimal applications have  e
 no requirements for a file system, multiple processes, or I/O via          e
 specific device drivers.  The minimal realtime profile, however, will      e
 specify the POSIX.4a threads extension to support multiple flows of        e
 control.                                                                   e

 The second type of embedded application is often used in control systems.  e
 Realtime controller applications require a file system and threads, but    e
 not multiple processes.                                                    e









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 246                                          7 POSIX SP Profiling Efforts






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 7.2.5.2.2  Mid-Range Realtime Applications                                 e

 Mid-range or intermediate-level realtime profiles are targeted at          e
 compute-oriented applications that are typically used in avionics, radar   e
 systems, submarines, and medical imaging equipment, as well as             e
 controllers that control a group of robots or a subsystem on the factory   e
 floor.  These applications tend to run on platforms that are dedicated to  e
 a single application set or mission mode.                                  e

 The design complexity of such dedicated realtime applications varies from  e
 simple to complex to accommodate a range of requirements.  Such            e
 requirements may include sophisticated signal processing capabilities,     e
 but do not necessarily include a file system.  A profile that satisfies    e
 these requirements would likely specify most of the POSIX.4 functionality  e
 (except for file system facilities), along with relevant options from the  e
 POSIX.4 and POSIX.1 {2} standards and the POSIX.4a threads extension.      e

 7.2.5.2.3  High-End Realtime Applications                                  e

 High-end realtime applications are applicable to complex, multipurpose     e
 realtime systems.  Such multipurpose realtime systems typically are used   e
 in military command and control, in space station control systems, in      e
 systems that control robot or factory subsystems, as the operating system  e
 for high-end simulation systems, and at high-functionality realtime        e
 application that are paced by operator interaction.                        e

 The current realtime, multipurpose profile is geared to full-function      e
 realtime systems such as simulation applications and embodies most of the  e
 existing practice in the simulator world.  Since simulation systems have   e
 a greater design complexity than embedded or mid-range systems, and need   e
 much greater functionality, the multipurpose realtime profile will most    e
 likely require all or most of the POSIX.4 and POSIX.1 {2} standards.       e
 This profile does not require threads.  It does, however, specify the X11  e
 window system as the basis for a human-computer interface.                 e

















              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 7.2 General Purpose POSIX SPs                                         247



















































 __________
  4) Refer to the earlier footnote on _i_n_t_e_r_n_a_t_i_o_n_a_l _h_a_r_m_o_n_i_z_a_t_i_o_n.          e



















                                                               P1003.0/D14






                                  Annex A
                               (informative)
                Considerations for Developers of POSIX SPs




 A.1  Introduction

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _B_o_b _G_a_m_b_r_e_l

 The contents of this Annex are illustrative of rules that might be
 developed for the submitters of POSIX Standardized Profiles (SPs).

 This Annex contains modifications and comments relating to the use of the
 _T_C_O_S-_S_S_C _P_O_S_I_X _S_t_a_n_d_a_r_d_s _S_t_y_l_e _G_u_i_d_e {B6} in POSIX SPs.



 A.2  Scope

 While Section 6 addressed profiles generally, this Annex addresses
 considerations for developers of formal POSIX Standardized Profiles.  It
 builds directly upon the concepts, principles, and guidance of Section 6.

 _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s:  _T_h_i_s _A_n_n_e_x _i_s _n_o_t _c_o_m_p_l_e_t_e, _i_n _t_h_a_t _m_o_r_e _w_o_r_k _i_s
 _r_e_q_u_i_r_e_d _i_n _t_h_e _d_o_m_a_i_n _o_f _P_O_S_I_X _p_r_o_f_i_l_e_s.

 _F_u_t_u_r_e _w_o_r_k _i_n _t_h_e _a_r_e_a _o_f _p_r_o_f_i_l_i_n_g _w_i_l_l _b_e _d_o_n_e _b_y _I_E_E_E _a_n_d _t_h_e
 _s_t_a_n_d_a_r_d_s _c_o_m_m_u_n_i_t_y.  _T_h_i_s _d_o_c_u_m_e_n_t, _a_n_d _t_h_e _g_u_i_d_a_n_c_e _i_t _p_r_o_v_i_d_e_s, _w_i_l_l
 _b_e _u_p_d_a_t_e_d _a_s _a_p_p_r_o_p_r_i_a_t_e.  _T_h_e _m_a_j_o_r _a_r_e_a_s _e_x_p_e_c_t_e_d _t_o _b_e _a_d_d_r_e_s_s_e_d _a_r_e:

     - _I_n_t_e_r_n_a_t_i_o_n_a_l _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _c_o_n_s_i_d_e_r_a_t_i_o_n_s

     - _C_o_n_f_o_r_m_a_n_c_e _i_s_s_u_e_s

     - _T_a_x_o_n_o_m_y _o_f _P_O_S_I_X _S_P_s

     - _R_e_g_i_s_t_r_a_t_i_o_n _o_f _P_O_S_I_X _S_P_s

     - _D_e_l_e_g_a_t_i_o_n _o_f _a_u_t_h_o_r_i_t_y _t_o _c_a_l_l _s_o_m_e_t_h_i_n_g _a _P_O_S_I_X _S_P (_N_o_t_e:
       _C_u_r_r_e_n_t_l_y, _t_h_i_s _d_o_c_u_m_e_n_t _d_o_e_s _n_o_t _p_r_o_h_i_b_i_t _a_n_o_t_h_e_r _g_r_o_u_p _b_e_s_i_d_e
       _I_E_E_E _f_r_o_m _c_a_l_l_i_n_g _t_h_e_i_r _d_o_c_u_m_e_n_t _a _P_O_S_I_X _S_P.)



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 A.2 Scope                                                             249






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - _C_l_a_r_i_f_i_c_a_t_i_o_n _o_f _b_a_s_e _s_t_a_n_d_a_r_d_s _r_e_f_e_r_e_n_c_i_n_g _i_s_s_u_e_s _s_u_c_h _a_s
       _s_u_b_s_e_t_t_i_n_g _a_n_d _t_h_e _h_a_n_d_l_i_n_g _o_f _o_p_t_i_o_n_s

     - _E_d_i_t_o_r_i_a_l _i_s_s_u_e_s _s_u_c_h _a_s _g_u_i_d_a_n_c_e _o_n _t_h_e _c_o_r_r_e_c_t _l_e_v_e_l _o_f _d_e_t_a_i_l

     - _A_d_d_i_t_i_o_n_a_l _g_u_i_d_a_n_c_e _o_n _r_e_f_e_r_e_n_c_i_n_g _b_a_s_e _s_t_a_n_d_a_r_d_s _a_n_d ``_s_t_a_n_d_a_r_d_s
       _i_n _p_r_o_g_r_e_s_s''



 A.3  The Role of POSIX SPs

 In 6.3.3.5, a classification scheme was given for profiles in which three
 different ``types'' were identified.  That scheme is based, essentially,
 on the scope covered by the profile.  Another useful classification
 scheme, based on scope and on who develops the profiles, is presented in
 this annex.

 Figure A-1 shows these classes of profiles and the relationships between
 them and base standards.

 _________________________________________________________________________




















 _________________________________________________________________________
             Figure A-1  -  Universe of Profiles and Standards


 Base standards cover a universe of diverse needs.  POSIX base standards
 (e.g., POSIX.1 {2}, P1003.4, ...) cover a narrower set of needs related
 to ``POSIX.''  In the figure, the POSIX base standards are shown as a


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 250                          A Considerations for Developers of POSIX SPs






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 small subset of the larger world of base standards.

 At the other end of the spectrum, organization-specific (e.g., company-
 specific) profiles are large in number and range even more widely in
 their coverage.  (There are many more organizations procuring systems,
 and effectively writing profiles, than there are committees writing
 standards.)

 Industry-specific profiles are based on specific industry needs.  From
 the point of view of the organization-specific profile writer, industry
 specific profiles are applicable to many organizations (in the same
 industry), and hence are possibly not precisely what any specific
 individual organization needs.  They address the broad consensus of the
 industry, from which there is usually deviation when you look at
 individual organizations whose needs range further.

 Standardized Profiles are formal balloted documents.  POSIX SPs are the
 subset of standardized profiles that pertain to the POSIX base standards.
 While not limited to just POSIX base standards, POSIX SPs nonetheless
 provide a distinctly POSIX-oriented view of the base standards.

 An organization wishing to procure a ``POSIX'' based system, then, could
 first develop its own organization-specific profile, which it could base
 on POSIX-oriented industry-specific profiles (if available), which in
 turn could be based on POSIX SPs, which of course are based on the
 various POSIX base standards.

 POSIX SPs provide an industry-neutral building block for creating
 industry specific profiles.  The developers of POSIX SPs do not have to
 have knowledge of any particular industry.  They furthermore help ensure
 coherence among the many base standards referenced, particularly among
 the various POSIX base standards.  As such, probably, most POSIX SPs will
 be created by the IEEE POSIX working groups meeting concurrently with
 IEEE POSIX base standards working groups.  Meeting concurrently at the
 same place helps ensure the coherence of the base standards and the
 harmony among the POSIX SPs.



 A.4  Special Rules for POSIX SPs

 While no rules have yet been developed by IEEE for POSIX SPs, the
 remainder of this annex gives examples of what such rules might say and
 identifies some issues for which rules might be drafted.

 The following criteria for calling a profile a POSIX SP were developed
 according to some general principles that have the aim of giving definite
 value to the word ``POSIX'' when used with regards to profiles.  The
 general principles are:


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 A.4 Special Rules for POSIX SPs                                       251






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     (1)  There is minimum content.  Specifically, a POSIX SP must
          reference some part of the suite of POSIX base standards.
          (Which part specifically is contentious.)

     (2)  The POSIX SP must follow a specific approach to conformance
          (specifically the P1003.3.1 test methodology.)

     (3)  The POSIX SP must adhere to the POSIX Reference Model.

     (4)  There is maximum content; i.e., some consideration must be given
          to how the POSIX SP goes beyond the POSIX OSE as described in
          this guide.

     (5)  Exceptions to the previous principles are expected, requiring a
          rule-making and enforcement body to make those exception
          decisions.

 POSIX SPs are Standardized Profiles that are related to ``POSIX.''  This
 subclause specifies the rules that need to be followed that distinguish
 POSIX SPs from ``Non-POSIX SPs''.

 Each POSIX SP is based on, and shall include, one of the following two
 base standards sets:

     (1)  POSIX.1 {2} or POSIX.2 (as verified by the P1003.3 methodology),
          or

     (2)  A particular subset of POSIX.1 {2} and P1003.4 that is being
          specified for a Minimal Realtime profile (as verified by the
          P1003.3 methodology.)

 Additionally, each POSIX SP adheres to the structure defined by the POSIX
 OSE reference model.

 An approved POSIX SP shall make reference only to base standards
 identified in this guide (1003.0) as being part of the POSIX OSE.  Two
 specific exceptions to this general rule are allowed for as described
 here:

     (1)  Reference can be made to required base standards that are
          clearly outside of the scope of the POSIX OSE.  Examples of the
          functionality that may require the use of this expedient are:

           - Physical connectors

           - Electrical characteristics

           - Safety requirements



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 252                          A Considerations for Developers of POSIX SPs






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          Such reference to items outside the scope of the POSIX OSE shall
          be justified on a case-by-case basis.  It shall be accompanied
          by details of the body responsible for the distribution and
          maintenance of the referenced base standard.

     (2)  Reference can be made to required base standards that are being
          proposed for inclusion in a future version of the guide.
          Examples of this would be specification of a later version of a
          base standard that is already included within the POSIX OSE, or
          of an additional programming language base standard, not yet
          included within the POSIX OSE.

          In such cases, the POSIX SP should be identified as a POSIX
          Preliminary SP and the specific references should be clearly
          noted and justified on a case by case basis.

 A POSIX Preliminary Standardized Profile (POSIX Preliminary SP) is a
 POSIX SP that satisfies all requirements of a POSIX SP except that it is
 not a subset of the POSIX OSE.  [It therefore contains at least one
 standard or profile that is outside the POSIX OSE.  It is expected that
 application would be made to POSIX.0 to include the standard(s) or
 profile(s) in the POSIX OSE.]

 A further restriction of POSIX SPs is the necessity to (normatively)
 reference only standards that are recognized by the IEEE.  This is
 limited to IEEE and ISO standards.

 Approval of a POSIX SP shall not change the status of any documents
 referenced by it.

 The development of a POSIX SP may indicate the need to modify or to add
 to the requirements specified in a base standard.  In this case, it is
 necessary for the POSIX SP developer to liaise with the body responsible
 for that base standard so that the required changes may be made through
 established methods such as defect reporting, amendment procedures, or
 the introduction of new work.



 A.5  Other Issues

 A significant number of issues remain to be addressed concerning the
 management of POSIX SP development.  Some of the issues and the concerns
 are summarized here.







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 A.5 Other Issues                                                      253






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Coherence

 The insurance of coherence among the many base standards referenced by a
 profile has been found by profile writers to be an onerous task.  The
 profile writer's burden could be eased significantly if base standards
 writers address coherence at the outset.  Specifically, all the P1003.x
 base standards should be developed to maximize their coherence.  This is
 seen as a management issue for TCOS-SEC, the sponsoring body of the
 P1003.x standards.


 Conformance

 The development of conformance statements and test methods for profiles
 is a significant challenge for profile writers.  The challenge is most
 acute in the area of conformance of standards that are being developed
 outside of P1003.  A premise for the profile writing rules associated
 with conformance must be that the profile writers are not really experts
 in the referenced standards.  Profile writers (especially at this early
 period in their development) must not be overburdened with untested
 conformance writing rules.  A possible solution is to create a new
 project under the auspices of P1003.3 to actually generate new test
 methods and actually write the necessary assertions for the first
 profile.  (This approach was used also for the initial POSIX base
 standard.)


 Base Standards Working Groups

 Because profile writers are in some sense the customers of base
 standards, it is important for base standards writers to address with
 priority and urgency the gaps identified in the development of POSIX SPs.


 Scope and Number of POSIX SPs

 How many different POSIX SPs are appropriate and how broadly ranging
 should be their scope?  Should POSIX SPs be rather narrowly focused,
 spanning just a few base standards, or should they address a large number
 of base standards?


 Issues Pertaining to Referencing Base Standards

 Many practical writing issues pertain to referencing, for instance, parts
 of base standards.  This includes not only referencing options, but even
 the concept of subsetting, or reducing the functionality of a base
 standard.  Also an issue is how to reference multiple versions of the
 same standard (e.g., two different COBOL standards.)


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 254                          A Considerations for Developers of POSIX SPs






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 POSIX SP Procedures and Rules

 What does it mean to be a POSIX SP?  Rule making for use of the word
 ``POSIX'' must address criteria for such use.  Also, many issues remain
 to be resolved in the area of ballot procedures.  Should IEEE delegate to
 others the ability to develop POSIX SPs?  If so, should IEEE maintain a
 registry of such efforts?



 A.6  Conformance to a POSIX SP

 A POSIX SP must address test methods for itself.  In the simplest case,
 testing the base standards referenced is sufficient.  In more complex
 cases, additional test methods will be necessary.  In the worst case (if
 a base standard is subsetted, for example), the test methods for the base
 standards may have to be rewritten or expanded within the POSIX SP.

 At the same time, P1003.3 will have to consider revisions to the _T_e_s_t
 _M_e_t_h_o_d_s _f_o_r _M_e_a_s_u_r_i_n_g _C_o_n_f_o_r_m_a_n_c_e _t_o _P_O_S_I_X to address test methods for
 POSIX SPs (e.g., additional assertion types, minimum requirements for
 testing POSIX SPs, ...)



 A.7  Structure of Documentation for POSIX SPs

 This clause gives specific format and content requirements to profile
 writers who are developing POSIX SPs.


 A.7.1  Principles

 The requirements for content and format of POSIX SPs are based on the
 following principles:

     (1)  Profiles shall be directly related to base standards and
          conformance to profiles shall imply conformance to base
          standards.

     (2)  POSIX SPs shall follow the rules for drafting and presentation
          of POSIX SPs detailed here.

     (3)  POSIX SPs are intended to be concise documents that do not
          repeat the text of the base standards.

     (4)  Profiles making identical use of particular base documents shall
          be consistent, down to the level of identical wording in the
          POSIX SPs for identical requirements.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 A.7 Structure of Documentation for POSIX SPs                          255






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 A.7.2  Multipart POSIX SPs

 Many profiles will be documented and published as individual POSIX SPs.
 However, where close relationships exist between two or more profiles, a
 more appropriate technique can be used.

 Common text between related profiles is essential to ensure consistency,
 portability, and interworking, to avoid unnecessary duplication of text,
 and to aid writers and reviewers of POSIX SPs.

 A _s_i_n_g_l_e-_p_a_r_t _P_O_S_I_X _S_P shall not contain the definition of more than one
 profile.

 The following rules apply to _m_u_l_t_i_p_a_r_t _P_O_S_I_X _S_P_s:

     (1)  A multipart POSIX SP shall contain the definition of a complete
          profile or of a related set of profiles.

     (2)  A part of a multipart POSIX SP may contain a section of the
          definition of one or more profiles.

     (3)  Where a multipart POSIX SP includes more than one profile, the
          part structure shall permit each profile to be the subject of a
          separate ballot; i.e., its constituent profiles shall be clearly
          identifiable, and the multipart structure shall ensure that this
          can be accomplished.

     (4)  Wherever possible, the references made from one part to another
          should be to complete parts.  However, controlled use of one-way
          references to sections of other parts is permitted in order to
          obtain a reasonable multipart structure.

 Because there may also be potential disadvantages from overuse of the
 multipart POSIX SP capability, such as difficulties in gaining approval
 for a complex linked set of parts, or reduction of the content of a part
 to a small amount of text, considerable care should be taken with its
 use.
 NOTES:

     (1)  When a section of text appears in several profiles,
          possibilities exist for sharing the corresponding code (etc.)
          for the implementation of several profiles, and the tests
          applicable to the use of the referenced base standards will be
          applicable to the testing of several profiles.

     (2)  It follows that it is in the interest of the implementors to
          promote the identification of common sections of text as parts
          of POSIX SPs, but even more to promote, in future
          standardization and profile work, the use of already defined


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 256                          A Considerations for Developers of POSIX SPs






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          parts of POSIX SPs, so that profiles fall into a few ``common
          molds.''  In particular, this allows implementation of a part of
          a POSIX SP with confidence that it may be used in the
          implementation of profiles as yet undefined, so that products
          are open to future development.

     (3)  Possibilities exist for a complete profile to be referenced from
          within the definition of another profile.



 A.8  Rules for Drafting and Presentation of POSIX SPs

 Throughout this Annex, which is concerned with documentation content and
 layout, reference is made to POSIX SPs.  A POSIX SP, or part thereof, may
 contain a whole profile definition or part of one or more profile
 definitions.  The wording of the Annex assumes that it is describing an
 undivided POSIX SP that defines one profile in its entirety.  Its
 application to the other cases is easily deduced.  Note, however, that
 each part of a Multipart POSIX SP shall use the same format as far as
 appropriate.


 A.8.1  General Arrangement

 The elements that together form a POSIX SP are classified into three
 groups:

     (1)  Preliminary elements are those elements that identify the POSIX
          SP, introduce its content, and explain its background, its
          development, and its relationship with other standards and POSIX
          SPs.

     (2)  Normative elements are those elements setting out the provisions
          with which it is necessary to comply in order to be able to
          claim conformity with the POSIX SP.

     (3)  Supplementary elements are those elements that provide
          additional information intended to assist the understanding or
          use of the POSIX SP.

 These groups of elements are described in the following clauses.









              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 A.8 Rules for Drafting and Presentation of POSIX SPs                  257






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 A.8.2  Preliminary Elements

 A.8.2.1  Foreword

 The foreword shall appear in every POSIX SP.  It consists of a general
 part giving information relating to the organization responsible and a
 specific part giving as many of the following as are appropriate:

     - An identification of the organization or committee that prepared
       the POSIX SP; information regarding the approval of the POSIX SP

     - A statement that the POSIX SP cancels or replaces other documents
       in whole or in part

     - A statement of significant technical changes from the previous
       edition

     - A statement of which annexes are normative and which are
       informative

 A.8.2.2  Introduction

 The introduction shall appear in every POSIX SP.  It gives specific
 information about the process used to draft the POSIX SP and about the
 degree of international harmonization that it has received.


 A.8.3  General Normative Elements

 A.8.3.1  Title

 The title shall be composed of the following three elements:

     (1)  An introductory element:  _S_t_a_n_d_a_r_d _f_o_r _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y

     (2)  An identification element:  _P_O_S_I_X _S_t_a_n_d_a_r_d_i_z_e_d _P_r_o_f_i_l_e

     (3)  A main element indicating the subject matter of the POSIX SP.
          For a Multipart POSIX SP, this element shall be subdivided into
          a general title element common to all parts, and a specific
          title element for each part;  where necessary, this specific
          element may include the identifier of an individual profile.
          The first word of this element should be the word ``POSIX''.

 Example:






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 258                          A Considerations for Developers of POSIX SPs






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

       Standard for Information Technology --
       POSIX Standardized Profile --
       POSIX Transaction Processing

 A.8.3.2  Scope

 This element contains two subclauses as follows:

     (1)  General

          This element shall appear at the beginning of the POSIX SP or
          POSIX SP part to define without ambiguity the purpose and
          subject matter of the document, thereby indicating the limits of
          its applicability.  It shall not contain requirements.

     (2)  Scenario

          If the POSIX SP or POSIX SP part defines a profile, it shall
          include (where appropriate) the ``scenario'' of the profile;
          i.e., an illustration of the environment within which it is
          applicable.  This may show in a simplified graphic form how this
          fits within the POSIX Reference Model.

 A profile should first introduce the functional area being addressed and
 the applications activities within that area.  The requirements that have
 been addressed should be delineated, as well as those areas outside of
 the scope of the profile.

 A.8.3.3  Normative References

 This element shall give a list of normative documents (base standards),
 with their titles and publication dates, to which reference is made in
 the text in such a way as to make them indispensable for the application
 of the POSIX SP.  Where published amendments or technical errata to base
 standards are relevant to the definition of the profile in such a way as
 to have a potential impact on interworking or portability, they shall be
 explicitly referenced here.

 Reference shall also be made to this guide.


 A.8.4  Technical Normative Elements

 A.8.4.1  Requirements

 This element includes clauses relating to the use made of each of the
 main base standards referenced in the profile definition.  The content
 and layout of these clauses are not defined, but can be tailored to the
 type of material that has to be specified in each case.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 A.8 Rules for Drafting and Presentation of POSIX SPs                  259






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 The information given shall not repeat the text of the base standards,
 but shall define the choices made in the profile of classes, subsets,
 options and ranges of parameter values.  It shall be in the form of
 conformance requirements and may, where appropriate, be given in tabular
 form.

 See 6.3.3 for more detail concerning the nature of the content required
 in this element of a POSIX SP.

 A.8.4.2  Normative Annexes

 Normative annexes are integral sections of the POSIX SP that, for reasons
 of convenience, are placed after all other normative elements.  The fact
 that an annex is normative (as opposed to informative) shall be made
 clear by the way in which it is referred to in the text, by a statement
 to this effect in the foreword, and by an indication at the head of the
 annex itself.


 A.8.5  Supplementary Elements

 A.8.5.1  Informative Annexes

 Informative annexes give additional information and are placed after the
 normative elements of a POSIX SP.  They shall not contain requirements.
 The fact that an annex is informative (as opposed to normative) shall be
 made clear by the way in which it is referred to in the text, by a
 statement to this effect in the foreword, and by an indication at the
 head of the annex itself.

 Informative annexes provide a point for documenting useful information
 for the users of a profile that poses no requirements.  Such annexes can
 include:

     (1)  Specification of additional standards or options that will make
          the profile useful for specific locales (character sets, etc.)

     (2)  Pointers to the referenced standards and information on ordering
          these

     (3)  Pointers to related specifications that may provide additional
          insight or potentially serve to fill gaps in the profile

     (4)  Comments and concepts in using the profile for various target
          readers.  This could include use in procurements (perhaps cross
          referencing related procurement standards like the FIPS in the
          US).  The annex may be used to provide recommendations for use
          that are not warranted in the standard (e.g., ``Algol is not
          recommended for new applications development'').


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 260                          A Considerations for Developers of POSIX SPs






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

































































                                                               P1003.0/D14






                                  Annex B
                               (informative)
                               Bibliography




 _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s:  _T_h_i_s _a_n_n_e_x _i_s _n_o_t _c_o_m_p_l_e_t_e.  _I_t _s_h_o_u_l_d _i_n_c_l_u_d_e         _e
 _r_e_f_e_r_e_n_c_e_s _t_o _s_t_a_n_d_a_r_d_s, _b_o_o_k_s, _a_r_t_i_c_l_e_s, _e_t_c., _t_h_a_t _a_r_e _n_o_t _r_e_q_u_i_r_e_d _f_o_r  _e
 _a_n _i_n_t_e_g_r_a_l _u_n_d_e_r_s_t_a_n_d_i_n_g _o_f _t_h_e _d_o_c_u_m_e_n_t (_a_s _a_r_e _t_h_e _e_n_t_r_i_e_s _i_n           _e
 _N_o_r_m_a_t_i_v_e _R_e_f_e_r_e_n_c_e_s).  _I_t _c_u_r_r_e_n_t_l_y _c_o_n_s_i_s_t_s _o_n_l_y _o_f _s_a_m_p_l_e _e_n_t_r_i_e_s.  _I_t  _e
 _w_i_l_l _b_e _r_e_p_l_a_c_e_d _i_n _a _l_a_t_e_r _d_r_a_f_t.                                         _e

 {B1}  ISO 7498: 1984, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_-
       _c_o_n_n_e_c_t_i_o_n--_B_a_s_i_c _R_e_f_e_r_e_n_c_e _M_o_d_e_l.1)

 {B2}  ISO 8072: 1986, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s _I_n_t_e_r_-
       _c_o_n_n_e_c_t_i_o_n--_T_r_a_n_s_p_o_r_t _s_e_r_v_i_c_e _d_e_f_i_n_i_t_i_o_n.

 {B3}  ISO/IEC 8073: 1988, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_O_p_e_n _S_y_s_t_e_m_s
       _I_n_t_e_r_c_o_n_n_e_c_t_i_o_n--_C_o_n_n_e_c_t_i_o_n _o_r_i_e_n_t_e_d _t_r_a_n_s_p_o_r_t _p_r_o_t_o_c_o_l
       _s_p_e_c_i_f_i_c_a_t_i_o_n.2)

 {B4}  CCITT Recommendation X.25, _I_n_t_e_r_f_a_c_e _b_e_t_w_e_e_n _d_a_t_a _t_e_r_m_i_n_a_l
       _e_q_u_i_p_m_e_n_t (_D_T_E) _a_n_d _d_a_t_a _c_i_r_c_u_i_t-_t_e_r_m_i_n_a_t_i_n_g _e_q_u_i_p_m_e_n_t (_D_C_T) _f_o_r
       _t_e_r_m_i_n_a_l_s _o_p_e_r_a_t_i_n_g _i_n _t_h_e _p_a_c_k_e_t _m_o_d_e _a_n_d _c_o_n_n_e_c_t_e_d _t_o _p_u_b_l_i_c _d_a_t_a
       _n_e_t_w_o_r_k_s _b_y _d_e_d_i_c_a_t_e_d _c_i_r_c_u_i_t.3)

 {B5}  CCITT Recommendation X.212, _I_n_f_o_r_m_a_t_i_o_n _p_r_o_c_e_s_s_i_n_g _s_y_s_t_e_m_s--_D_a_t_a
       _c_o_m_m_u_n_i_c_a_t_i_o_n--_D_a_t_a _l_i_n_k _s_e_r_v_i_c_e _d_e_f_i_n_i_t_i_o_n _f_o_r _O_p_e_n _S_y_s_t_e_m_s
       _I_n_t_e_r_c_o_n_n_e_c_t_i_o_n.




 __________
  1) ISO documents can be obtained from the ISO office, 1, rue de Varembe',
     Case Postale 56, CH-1211, Gene`ve 20, Switzerland/Suisse.
  2) IEC documents can be obtained from the IEC office, 3, rue de Varembe',
     Case Postale 131, CH-1211, Gene`ve 20, Switzerland/Suisse.
  3) CCITT documents can be obtained from the CCITT General Secretariat,
     International Telecommunications Union, Sales Section, Place des
     Nations, CH-1211, Gene`ve 20, Switzerland/Suisse.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 262                                                        B Bibliography






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 {B5}  ANSI X3.113-19874), _I_n_f_o_r_m_a_t_i_o_n _s_y_s_t_e_m_s--_P_r_o_g_r_a_m_m_i_n_g _l_a_n_g_u_a_g_e--_F_U_L_L
       _B_A_S_I_C.

 {B6}  IEEE Computer Society Technical Committee on Operating Systems and
       Application Environments Standards Subcommittee.  _T_C_O_S-_S_S_C _P_O_S_I_X
       _S_t_a_n_d_a_r_d_s _S_t_y_l_e _G_u_i_d_e.

 {B7}  American Telephone and Telegraph Company.  _S_y_s_t_e_m _V _I_n_t_e_r_f_a_c_e
       _D_e_f_i_n_i_t_i_o_n (_S_V_I_D), _I_s_s_u_e_s _2 _a_n_d _3.  Morristown, NJ:  UNIX Press,
       1986, 1989.

 {B8}  /usr/group Standards Committee.  _1_9_8_4 /_u_s_r/_g_r_o_u_p _S_t_a_n_d_a_r_d.  Santa
       Clara, CA:  UniForum, 1984.

 {B9}  X/Open Company, Ltd.  _X/_O_p_e_n _P_o_r_t_a_b_i_l_i_t_y _G_u_i_d_e, _I_s_s_u_e _3.  Englewood
       Cliffs, NJ:  Prentice-Hall, 1989.





























 __________
  4) ANSI documents can be obtained from the Sales Department, American
     National Standards Institute, 1430 Broadway, New York, NY 10018.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Annex B Bibliography                                                  263








































































                                                               P1003.0/D14






                                  Annex C
                               (informative)
                   Standards Infrastructure Description




 _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _W_e_n_d_y _R_a_u_c_h



 C.1  Introduction

 This annex provides a brief summary of the major national and
 international organizations working on the standardization of information
 technology.

 There are two major categories of open standards organizations.  One
 consists of formally-recognized standards bodies, responsible for
 definition and dissemination of public standards.  Their specifications
 are known as formal or de jure standards.  International, national, and
 regional standards groups, and some professional and technical
 organizations' standards groups are examples of formal standards bodies.
 Organizations specifying standards for open system usually give
 precedence to international standards first, then regional, national, and
 finally professional group standards.

 The other standards organization category consists of informal bodies.
 Informal standards bodies are typically created by suppliers or users of
 information technology, usually using a consensus method, to enable the
 implementation of standards.  They produce specifications known as
 industry standards or de facto standards.  Certain trade associations,
 industry groups, vendor consortia, and user groups are examples of
 informal standards bodies.  For informal specifications to be approved as
 formal standards (e.g., international or national standards) informal
 standards groups typically submit their specifications to formal
 standards organizations.

 The term ``de facto standard'' is sometimes applied to popular vendor-
 defined systems.  Such systems, however, are closed systems, often
 controlled in a proprietary fashion.  Although they have value, closed de
 facto standards are not the subject of this guide.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.1 Introduction                                                      265






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Most standards bodies support three types of status for their standards
 or specifications--approved, draft, and work item.  An approved standard
 is one that has been fully ratified by whatever means the approving
 standards body uses.  A draft standard is one that has yet to be fully
 ratified, such as an ISO DIS (Draft International Standard) or a CEN ENV.
 Work item is a catch-all phrase for everything else, such as immature
 specifications, technical reports, etc., that have not yet achieved draft
 status.


 C.1.1  International Standards Bodies Overview

 Standards with the highest status are internationally agreed ones.  In
 information technology, these are produced and published by the
 International Organization for Standardization (ISO).  Other standards
 and/or recommendations are issued by the International Electrotechnical
 Commission (IEC), the International Telecommunication Union (ITU), and
 the CCITT.  International standards bodies participants are normally
 countries and trade bodies, rather than individual suppliers or users.


 C.1.2  National Standards Bodies Overview

 Like the international standards bodies, most national bodies do not
 admit either suppliers or users directly, but receive representatives
 from interested trade bodies.  In general, the national bodies support
 and adopt the international standards, developing national standards only
 if no international standards are available, or to meet special national
 requirements.  Each country has a national body that is the formal
 representative to the international standards groups.

 The relationship between the major international and national standards
 groups is shown in Figure C-1.


 C.1.3  International and National Standards Bodies Relationship

 Nongovernment standards organizations include trade associations,
 professional and technical societies, vendor consortia, user groups, and
 other special interest groups.  Actual standards development occurs
 within these groups.  The standards specified by formal standards groups
 within this category typically are subsequently submitted to national or
 international standards organizations for approval.  Many informal bodies
 submit their specifications to formal bodies for approval as an
 accredited standard.  (See Figure C-1).






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 266                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________































 _________________________________________________________________________
 Figure C-1  -  Selected Major Standards and Standards-Influencing Bodies



 C.2  The Formal Standards Groups


 C.2.1  International and National Standards Organizations

 NOTE:  Only a few of the many national standards organizations are         e
 described in this subclause.  However, the activities of these groups are  e
 representative of national standards groups in general.                    e






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       267






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _A_F_N_O_R_:__A_s_s_o_c_i_a_t_i_o_n__F_r_a_n_c_a_i_s_e__d_e__N_o_r_m_a_l_i_z_a_t_i_o_n

 AFNOR is the French national standards body.  Its responsibilities
 include sourcing, coordinating, approving, and promoting standards,
 representing the French at international meetings, and controlling the
 use of the NF label--a trademark that shows compliance with a French
 national standard.  AFNOR publishes three types of standards documents--
 AFNOR-approved standards that are mandatory for use in the public sector,
 experimental standards that use new processes or techniques and whose use
 is voluntary, and information or guide standards.

 For further information, contact Association Francaise de Normalization
 (AFNOR), Tour Europe - Cedex 7, 92080 Paris La Defense, Telephone:  (1)
 42 91 55 55, Telex:  AFNOR 611 974F, Fax:  [phone].

 _A_N_S_I_:__A_m_e_r_i_c_a_n__N_a_t_i_o_n_a_l__S_t_a_n_d_a_r_d_s__I_n_s_t_i_t_u_t_e

 ANSI is the national standards coordinating and approval body for the
 United States.  A voluntary organization founded in 1918, the ANSI
 performs three major types of functions.

 First, the ANSI approves standards and accredits standards development
 groups and certification programs.  ANSI does not itself develop
 standards.  Instead, it approves voluntarily-submitted specifications
 that were developed by technical and professional societies, trade
 associations, and special interest groups, if these specifications and/or
 groups meet ANSI criteria for due process and consensus.

 ANSI accredits three types of organizations.  One is professional
 societies, such as the IEEE.  The second is committees formed for the
 exclusive purpose of developing standards, such as X3.  The third is
 accredited by ANSI to use the canvass method to develop standards.  Such
 organizations prepare a standard using their internal procedures.  Then
 they submit that standard to balloting by other organizations
 representing a variety of interests.  Last, they reconcile comments and
 objections returned.  The NIST is an organization accredited to use the
 canvass process for standards development.

 ANSI's second major function is to represent and coordinate US interests
 in international, nontreaty, and nongovernmental standards bodies.
 ANSI's third function is to be a clearinghouse for national,
 international, and foreign national standards.  ANSI membership is open
 to manufacturers, organizations, users, and communications carriers.  At
 present, more than 220 professional and technical societies and trade
 associations that develop standards in the US are ANSI members, as are
 1000 companies.

 For further information, contact American National Standards Institute
 (ANSI), 1430 Broadway, New York, NY 10018, [phone], Telex:


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 268                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 42 42 96 ANSI UI.

 _B_S_I_:__B_r_i_t_i_s_h__S_t_a_n_d_a_r_d_s__I_n_s_t_i_t_u_t_e

 BSI is the British national standards body and is responsible for
 promulgation of national standards.  The BSI determines the overall UK
 view toward international standards and conveys that back to the
 secretariat of the international committee.

 For further information, contact British Standards Institute, 2 Park
 Street, London W1A2BS, United Kingdom, Telephone:  [phone], Fax:
 44 1 629 05 06.

 _C_a_n_a_d_i_a_n__S_t_a_n_d_a_r_d_s__A_s_s_o_c_i_a_t_i_o_n__(_C_S_A_)

 The Canadian Standards Association (CSA), in conjunction with regulatory
 agencies and with the provincial and national governments of Canada,
 provides a single source for consensus-based standards development,
 conformance testing, and standards-based regulations creation.  The CSA
 has no single counterpart in the US.  Instead, the CSA handles selected
 functions from US testing organizations, the FCC, and ANSI.

 Membership in the CSA is open to any Canadian citizen, business, or
 organization.  Members of the CSA's technical committees developing
 standards are volunteers, drawn from consumers, manufacturers,
 government, labor, and consultants.  Membership is based on expertise in
 the field, and not, as in the US, mainly on having a vested commercial
 interest.  The CSA has over 900 committees handling various aspects of
 standards in areas such as the environment, electrical and electronics,
 communications and information processing, construction, energy,
 transportation and distribution, materials technology, and production
 management.

 CSA programs support Canadian industry and Canadian consumers where
 safety and quality of merchandise sold or made in Canada are concerned.
 To assure product quality and safety, the CSA offers fee-based testing
 services.  In performing such services, the CSA assumes that most
 manufacturers have the facilities to test their products before
 submitting them to the CSA for certification and approval.  If they do
 not, the CSA provides this service.  CSA certification involves the
 submission of the product or service by the supplier, the verification of
 that product or capability by the CSA, and then continued follow-up
 audits by the CSA to ensure that the quality of the product or service is
 maintained.

 For further information, contact (Address and phone number TBD).





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       269






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _C_C_I_T_T_:__C_o_m_i_t_e__C_o_n_s_u_l_t_a_t_i_f__I_n_t_e_r_n_a_t_i_o_n_a_l__d_e__T_e_l_e_g_r_a_p_h_i_e__e_t__T_e_l_e_p_h_o_n_i_e

 An international organization, the CCITT is part of the International
 Telecommunications Union, which is a United Nations treaty organization
 formed in 1865.  It is now a specialized agency of the United Nations.

 The CCITT's primary mission is to develop standards supporting the
 international interconnection and interoperability of telecommunications
 networks at interfaces with end-user systems, carriers, information and
 enhanced-service providers, and customer premises equipment.  Every four
 years, the CCITT publishes the results of its work as
 ``Recommendations.'' Its recommendations are law where communications in
 Europe are nationalized.

 Membership and participation in the CCITT are open to private companies;
 scientific and trade associations; and postal, telephone, and telegraph
 administrations.  CCITT's principal participants are telecommunications
 administrations and carriers.  Scientific and industrial organizations
 can participate as observers.  The US representative is the Department of
 State.

 For further information, contact International Consultative Committee on
 Telegraphy and Telephone, Central Administration Office, CH-1211, 2 rue
 de Varembe', Geneva, Switzerland,

 _C_E_N_/_C_E_N_E_L_E_C_/_C_E_P_T

 The Comite Europeen de Normalisation (CEN), Comite Europeen de
 Normalisation Electrotechnique (CENELEC), and the European Committee for
 Post and Telecommunications Administration are European regional
 standards committees responsible for developing and publishing European
 standards.  CEN is an association of EC (European Community) and EFTA
 (European Free Trade Association) members.  It is active in making
 members' standards into ISO standards and European standards.  CENELEC is
 the counterpart of CEN that deals exclusively with electrotechnical
 matters.  CEPT is the CEN counterpart that deals with telecommunications
 matters.

 CEN, CENELEC, and CEPT can be considered the European regional equivalent
 of ISO for two reasons.  First, they have as members the national
 standards bodies of their eighteen EC and EFTA member states.  Second,
 standards adopted by these organizations must be implemented in full as
 national standards, regardless of the way in which the member voted, and
 regardless of any standards that conflict with them must be withdrawn.
 CEN members, for example, agree to use its published standards in
 preference to national standards, wherever possible.

 CEN, CENELEC, and CEPT were created to improve the competitiveness of
 European enterprise by removing technical barriers to trade and


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 270                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 facilitating the free movement of goods within Europe.  To accomplish its
 aims, CEN, CENELEC, and CEPT perform the following tasks:

     - Create and promote European Standards (EN).

     - Rapidly create prestandards (ENV) in technology areas in which
       there is a high level of innovation or where it is felt that future
       standardization requires basic guidance.  ENVs are subjected to an
       experimental period of up to three years.

     - Create harmonization documents (HD) that are more flexible than
       European Standards so that the technical, historical, or legal
       circumstances pertaining to each country can be taken into account.

     - Set up a framework for European certification that supports the
       issuing of a European mark of conformity to certain standards and
       the mutual recognition of test results and inspections.

     - Promote the application within Europe of ISO standards and
       accelerate their production.

     - Work in liaison with European professional federations and numerous
       technical organizations to establish priority standards programs
       and contribute to the technical work.

 For further information, contact the European Committee for
 Standardization (CEN), European Committee for Post and Telecommunications
 Administration, 2 rue Brederode, Suite 5, B-1000 Brussels, Belgium,
 Telephone:  [phone], Telex:  26257 CENLEC.

 _D_I_N_:__D_e_u_t_s_c_h_e_s__I_n_s_t_i_t_u_t__f_u_r__N_o_r_m_u_n_g

 DIN is the German national standards body.  Its functions include those
 performed by the US's ANSI (e.g., developing national standards and
 representing Germany in international and European standards bodies such
 as ISO, the IEC, CEN, and CENELEC), in addition to test and certification
 functions that are not handled by US consensus standards organizations.
 Since a key DIN objective is eliminating technical barriers to free
 trade, DIN plays an active role in the international standards arena to
 ensure that German products can be used and accepted internationally.

 DIN standards are not mandatory within Germany.  DIN claims that it
 relies on the technical excellence of its standards to win converts.
 Further incentive for accepting DIN standards is provided because DIN
 standards serve as the basis for regulatory technical law in Germany.
 Also, without the DIN testing and inspection mark, no insurance carrier
 in Germany will write insurance for a product.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       271






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 DIN members include groups within Germany representing manufacturers, the
 academic community, user groups, user organizations (e.g., consumer
 advocate groups), the government, and trade unions.  Many DIN staff are
 supported by organizations or companies, rather than by DIN.  DIN
 presently has over 20000 standards.

 For further information, contact Deutsches Institut fur Normung,
 Burggrafenstrasse 6, Postfach 1107, D-1000 Berlin 30, Telephone:
 49 30 26 01-1, Fax: [phone].

 _I_E_C_:__I_n_t_e_r_n_a_t_i_o_n_a_l__E_l_e_c_t_r_o_t_e_c_h_n_i_c_a_l__C_o_m_m_i_s_s_i_o_n

 The International Electrotechnical Committee is the equivalent of ISO,
 but for electrotechnical standards.  ISO and the IEC have converged many
 of their information technology efforts to form JTC1.

 For further information, contact International Electrotechnical
 Commission (IEC), 3, rue de Varembe', CH-1211 Geneva 20, Switzerland,
 Telephone:  [phone], Fax:  [phone].

 _I_S_O_:__I_n_t_e_r_n_a_t_i_o_n_a_l__O_r_g_a_n_i_z_a_t_i_o_n__f_o_r__S_t_a_n_d_a_r_d_i_z_a_t_i_o_n

 ISO was established in its present form in 1947 with the aim of reaching
 international agreement on standards.  A voluntary, non-United Nations
 treaty, ISO's membership consists of delegations from standards bodies in
 participating nations.  ISO solicits comments from other groups as well,
 including ECMA, the IEEE, the NIST, and the CCITT.  ISO has a close
 relationship with the CCITT, which is, perhaps, the most influential of
 all the observer groups within ISO.

 ISO is responsible for the development and standardization of the Open
 Systems Interconnection (OSI) model.  It also considers items for
 standardization that were developed in other standards bodies, such as
 ANSI.  At present, for example, it is considering the core POSIX standard
 (P1003.1).

 For further information, contact the International Organization for
 Standardization, Central Secretariat, 1, rue de Varembe', CH-1211, Geneva,
 Switzerland-40.

 _J_I_S_C_:__J_a_p_a_n_e_s_e__I_n_d_u_s_t_r_i_a_l__S_t_a_n_d_a_r_d_s__C_o_m_m_i_t_t_e_e

 The Japanese Industrial Standards Committee (JISC) is the national
 standards body of Japan.  The JISC represents Japan at ISO and IEC,
 develops Japanese standards, and monitors and liaises with the
 standards-developing activities of other national organizations,
 especially those of the US.  The goal of the JISC is to ensure that
 Japanese industry can compete internationally in the information
 technology and telecommunications industries.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 272                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 The JISC has no true counterpart in other nations since the JISC has a
 special relationship with the Japanese government and major
 manufacturers.  For example, the JISC's secretariat is the Agency of
 Industrial Science and Technology, a division of the Ministry of
 International Trade and Industry (MITI), which plays a central role in
 Japanese industry.  The influence of this centralized national planning
 structure eliminates many areas of contention, including among companies
 with multinational branches, and facilitates the ability for Japanese
 standards groups to gain a consensus.

 Major Japanese manufacturers help plan and develop standards.  Foreign
 companies' involvement in the JISC is limited because of geographic and
 linguistic differences and because of restrictions on their meaningful
 participation.  Although large-scale manufacturers may participate, user
 groups and small manufacturers find participation very difficult.

 For information, contact Japanese Industrial Standards Committee, c/o
 Standards Department, Agency of Industrial Science and Technology,
 Ministry of International Trade and Industry, 1-3-1 Kasumigaseki,
 Chiyoda-ku, Telephone:  [phone], Fax:  [phone].

 _J_T_C_1_:__J_o_i_n_t__T_e_c_h_n_i_c_a_l__C_o_m_m_i_t_t_e_e__1

 The JTC1, established in 1987, is the first joint committee of the ISO
 TC97 (Information Processing Systems) and its subcommittees, with the IEC
 Technical Committee 83 (Information Technology Equipment) and the
 subcommittee IEC SC47B (Microprocessor systems).  The joint committee was
 formed to eliminate much of the two groups' standardization-activities'
 overlap and prevent the creation of incompatible standards for the same
 device or technology area.

 Although ISO and IEC are equal partners in the management of JTC1, most
 of JTC1's standards work grew out of ISO's information processing work.
 In fact, JTC1 has become one of the most important information technology
 standards organizations today because so many of the major ISO
 information technology standards being developed today are actually being
 produced by JTC1 groups.

 The JTC1's purpose is to develop international standards in the areas of
 information technology systems (including microprocessor systems) and
 equipment.  Microprocessor systems include, but are not limited to,
 microprocessor assemblies, and related hardware and software for
 controlling the flow of signals at the terminals of microprocessor
 assemblies.

 The JTC1 initially organized its standards work into four major
 groupings, each of which contains subcommittees that, in turn contain
 working groups.  The four main groupings and their subcommittees are:



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       273






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

    JTC1 Application Elements Group

          SC1:     Vocabulary

          SC7:     Software Engineering

          SC14:    Representation of Data Elements

          SC22:    Languages

    JTC1 Equipment and Media Group

          SC11:    Flexible Magnetic Media for Digital Data Interchange

          SC15:    Labeling and File Structure

          SC17:    Identification and Credit Cards

          SC23:    Optical Disk Cartridges for Information Interchange

          SC28:    Office Equipment

    JTC1 Systems Group

          SC6:     Telecommunications and Information Exchange Between
                   Systems

          SC13:    Interconnection of Equipment

          SC18:    Text and Office Systems

          SC21:    Information Retrieval, Transfer, and Management for OSI

    JTC1 Systems Support Group

          SC2:     Character Sets and Information Coding

          SC24:    Computer Graphics

          SC25:    Interconnection of Information Technology Equipment
                   (formerly IEC TC83)

          SC26:    Microprocessor Systems (formerly IEC TC47B)

          SC27:    Security Techniques (grew out of JTC1 SC20:  Data
                   Cryptographic Techniques)

 POSIX standardization work is being done within SC22's Working Group 15
 (SC22/WG15).  A JTC1 Special Working Group on Strategic Planning is


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 274                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 performing a technical study on Application Portability (AP).  This
 study's goal is to identify the standards that need to be written or
 revised to support application portability between hardware and software
 environments.

 The JTC1 is not involved in application-specific information technology
 areas, such as banking and industrial automation systems, nor is it
 concerned with microprocessor subsystems covered by the scopes of IEC
 TC22 on power electronics or TC86 on fiber optics.

 The JTC1 has liaison relationships with numerous ISO and IEC Technical
 Committees, as well as with the CCITT.

 Like ISO, membership in JTC1 consists of delegations from standards
 organizations in member countries.  At present, 23 countries participate
 in JTC1, and there are another 11 observer countries.  The ANSI holds the
 secretariat for JTC1.

 For further information, contact:  American National Standards Institute
 (ANSI), 1430 Broadway, New York, NY 10018, [phone], Telex:
 42 42 96 ANSI UI, or International Organization for Standardization
 (ISO), Central Secretariat, 1, rue de Varembe', CH-1211, Geneva,
 Switzerland-40.

 _S_G_F_S__(_S_p_e_c_i_a_l__G_r_o_u_p__o_n__F_u_n_c_t_i_o_n_a_l__S_t_a_n_d_a_r_d_i_z_a_t_i_o_n_)

 The Special Group on Functional Standardization (SGFS) is an ISO group,
 under JTC1, which is responsible for the international standardization
 process of profiles or functional standards.


 C.2.2  Nongovernment Formal Standards Organizations

 _E_C_M_A_:__E_u_r_o_p_e_a_n__C_o_m_p_u_t_e_r__M_a_n_u_f_a_c_t_u_r_e_r_s__A_s_s_o_c_i_a_t_i_o_n

 Established in 1961 to develop data processing standards, ECMA is a trade
 organization, open to any computer firm developing, manufacturing, or
 selling in Europe.  The ECMA has about 20 members, and approximately 13
 active Technical Committees.

 ECMA contributes to the ISO standards development efforts, in addition to
 issuing its own standards.  ECMA is particularly active in the
 development of higher layer protocols for OSI networking.  It also is
 developing a standard for a Portable Common Tool Environment (PCTE).

 For further information, contact European Computer Manufacturers
 Association, 114 rue du Rhone, CH-1204 Geneva, Switzerland, Telephone:
 41-22-735-36-34, Telex:  41 3237, Fax:  [phone].



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       275






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _E_I_A_:__E_l_e_c_t_r_o_n_i_c__I_n_d_u_s_t_r_i_e_s__A_s_s_o_c_i_a_t_i_o_n

 The EIA is a US trade organization, whose membership consists primarily
 of manufacturers.  The EIA has been a standards developer in the areas of
 electrical and electronic products and components since 1926.  Many of
 its standards have been submitted to ANSI and approved as ANSI standards.
 The EIA is best known for the RS-232-C standard.

 For further information, contact John Kinn, Vice President - Engineering,
 Electronic Industries Association (EIA), 2001 I Street NW, Washington, DC
 20036, [phone].

 _I_E_E_E_:__I_n_s_t_i_t_u_t_e__o_f__E_l_e_c_t_r_i_c_a_l__a_n_d__E_l_e_c_t_r_o_n_i_c__E_n_g_i_n_e_e_r_s

 The IEEE is a professional scientific, engineering, and educational
 society that develops and publishes standards and specifications in a
 variety of computer and engineering areas.  The standards and
 specifications published are of three types:  true standards, recommended
 practices, and guides.

 ``Standards'' are specifications with mandatory requirements.
 Recommended practices are specifications of procedures and positions
 preferred by the IEEE.  Guides are specifications that suggest
 alternative approaches to good practice, but make no clear-cut
 recommendations.  The IEEE is accredited by ANSI, and can, therefore,
 submit its standards directly to the ANSI board of Standards Review.  All
 new and revised IEEE standards are submitted to ANSI for review and
 adoption as ANSI standards.

 The IEEE Standards Board authorizes, coordinates, and approves all
 standards projects, and coordinates cooperation with other standards
 organizations.  Standards are proposed and sponsored by technical
 committees of the IEEE Societies, standards committees, or Standards
 Coordinating Committees (SCC), depending on the scope of the work.
 Either these committees or standards subcommittees manage the actual
 standards development and balloting.  The individual draft standards are
 specified in working groups inside the subcommittees--one working group
 per standard (see Figure C-2).

 IEEE membership is open to any dues-paying individuals.  Standards
 participants are individuals, not companies or organizations.  IEEE
 membership is required for voting, but not for participating in the
 development of draft standards.

 Approximately 30000 members are active in standards development.  More
 than 500 IEEE standards exist, and more than 800 standards projects are
 underway.  The IEEE also administers the secretariat or cosecretariat of
 17 American National Standards committees.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 276                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _________________________________________________________________________


































 _________________________________________________________________________
                   Figure C-2  -  IEEE Standards Diagram


 The most well known IEEE standards are the IEEE 802.3 CSMA/CD and 802.4
 token bus LANS, IEEE-488 bus, the National Electrical Safety Code, and
 the P1003.n POSIX standards.  The 802.3 and 802.4 standards are also
 approved ISO standards.  The core POSIX standard (POSIX.1 {2}) has been
 approved by ISO, and is now an ISO, as well as an IEEE, standard.  The
 POSIX.0 specifications, with which this document is concerned, will be,
 in IEEE parlance, a ``Guide'' to a POSIX Open System Environment.

 For further information, contact the Institute of Electrical and
 Electronics Engineers, Inc., 345 East 47th Street, New York, NY 10017,


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       277






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 USA.

 _N_I_S_T_:__N_a_t_i_o_n_a_l__I_n_s_t_i_t_u_t_e__o_f__S_t_a_n_d_a_r_d_s__a_n_d__T_e_c_h_n_o_l_o_g_y

 The National Institute of Standards and Technology (formerly the National
 Bureau of Standards) was established by an act of the US Congress on
 March 3, 1901 to advance, and facilitate the application of, US science
 and technology for public benefit.  Toward this end, the Institute for
 Computer Sciences and Technology (ICST) within the NIST, conducts
 research and provides technical advisory services to help Federal
 agencies acquire and apply computer technology.

 The NIST is a major driving force behind standards development.  Through
 the Institute for Computer Sciences and Technology, the NIST develops and
 publishes Federal Information Processing Standards (FIPS) for the United
 States.  Federal agencies to use in their computer equipment
 procurements.  Federal agencies are obligated to use these standards,
 where applicable.

 Federal computer standards also are widely used by the private sector,
 and often are adopted as ANSI standards.  Besides defining standards, the
 NIST has defined an Application Portability Profile (APP), which
 comprises a series of nonmandatory specifications and a guide for US
 government users to use in developing a portable, interoperable
 architecture and environment.

 The development and evolution of both FIPS and the APP is carried out in
 conjunction with users and vendors through an ongoing series of NIST-
 conducted Implementor Workshops and User Workshops (e.g., OSI
 implementors workshops, APP workshops, and Integrated Software
 Engineering Environment workshops).  The workshops provide forums for
 user and vendor feedback and comments on evolving NIST standards, and
 help ensure that there is a general commitment among vendors to building
 products that conform to the evolving NIST specifications.

 Additionally, the NIST develops test methods and performance measures to
 help users and vendors implement standards and to test the conformance of
 vendor implementations to FIPS specifications.  Among others, the NIST
 has test suites for most FIPS programming languages, FIPS Database SQL,
 and POSIX.1 {2}.  The POSIX.1 {2} conformance test suite, however, is
 based on the conformance-test assertions developed in the POSIX Test and
 Methods working group (P1003.3.1).

 Besides developing its own standards, NIST staff members participate in a
 number of other standards activities and organizations, including the
 ANSI X3 Committee on Information Processing Systems, ISO/IEC JTC1, CCITT,
 ECMA, and the IEEE.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 278                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 For further information, contact the National Institute of Standards and
 Technology, Gaithersburg, MD 20899, Telephone:  [phone].            e

 _T_1

 T1, established in 1984, is an ANSI-accredited standards body that is
 developing standards and technical reports.  The standards and reports
 are intended to support interconnection and interoperability of
 telecommunications networks at interfaces with end-user systems,
 carriers, information and enhanced-service providers, and customer
 premises equipment.

 Six T1 technical subcommittees are currently developing these standards
 and reports under the T1 Advisory Group.  The subcommittees also
 recommend positions on matters under consideration by other North
 American and international standards bodies.

 T1 Membership and full participation is available to all interested
 parties.  For further information, contact Alvin Lai, Exchange Carriers
 Standards Association, c/o T1 Secretariat, 5430 Grosvenor Lane, Suite
 200, Bethesda, Maryland 20814-2122, or call [phone].

 _X_3

 X3, established in 1961, is an ANSI-accredited standards body that
 develops computer, information processing, and office systems standards.
 X3 also participates in the development of international standards in
 these areas.  In addition, it serves as a Technical Advisory Group (TAG)
 to ANSI for most of the subcommittees working on international
 standardization projects within JTC1.  The Computer and Business
 Equipment Manufacturers Association (CBEMA) functions as X3's
 secretariat.

 X3 membership is open to all organizations, upon payment of a service
 fee.  The current membership includes computer manufacturers,
 communications carriers, user groups, and government agencies.  More than
 3200 volunteers from these organizations participate in the X3 standards
 work.  They are organized into about 85 technical groups, working on 700
 projects.

 Three standing committees report to X3:  the Standards Planning and
 Requirements Committee (SPARC), the Strategic Planning Committee (SPC),
 and the Secretariat Management Committee (SMC).  The following are the
 major X3 technical committees:

    Recognition

          X3A1     Optical Character Recognition



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.2 The Formal Standards Groups                                       279






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

    Media

          X3B5     Digital Magnetic Tape

          X3B6     Instrumentation Tape

          X3B7     Magnetic Disks

          X3B8     Flexible Disk Cartridges

          X3B9     Paper/Forms Layout

          X3B10    Credit/Identification Cards

          X3B11    Optical Digital Data Disks

    Data Management and Graphics

          X3H2     Database

          X3H3     Computer Graphics

          X3H3.6   Windowing Interfaces

          X3H4     Information Resource & Dictionary

    Languages

          X3J1     PL/1

          X3J2     Basic

          X3J3     Fortran

          X3J4     COBOL

          X3J7     APT

          X3J9     Pascal

          X3J10    APL

          X3J11    C

          X3J12    Dibol

          X3J13    Common Lisp




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 280                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

          X3J14    Forth

          X3J15    Databus

    Documentation

          X3K1     Computer Documentation

          X3K5     Vocabulary

    Data Representation

          X3L2     Codes and Character Sets

          X3L5     Labels and file Structure

          X3L8     Data Representation

    Communication

          X3S3     Data Communications

    Systems Technology

          X3T1     Data Encryption

          X3T2     Data Interchange

          X3T5     Open Systems Interconnection

          X3T9     I/O Interface

    Text

          X3V1     Office and Publishing Systems

 For more information, contact CBEMA, c/o X3 Secretariat, 311 First Street
 NW, Suite 500, Washington, DC 20001-2178, Telephone:  [phone].



 C.3  Related Organizations                                                 e

 The following organizations are some of the major trade associations,
 user groups, and professional bodies active in either promoting,
 implementing, or reviewing information technology standards.

                                                                            e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             281






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _C_B_E_M_A_:__C_o_m_p_u_t_e_r__a_n_d__B_u_s_i_n_e_s_s__E_q_u_i_p_m_e_n_t__M_a_n_u_f_a_c_t_u_r_e_r_s__A_s_s_o_c_i_a_t_i_o_n

 CBEMA is a trade organization whose primary function is to represent
 large manufacturers of hardware-based information technologies equipment
 in lobbying about public policy.  In addition, it provides education
 programs, information exchange forums, and deals with the industry's
 public image.

 CBEMA has long had an interest in standards.  It serves as the
 secretariat for X3.  It also offers a standards and technology program
 where its members can exchange information on standards issues and
 industry standards.

 CBEMA's members are mostly large manufacturers because its dues are tied
 to corporate revenues and structured in a way that makes it too expensive
 for small companies to join.  Members are either American companies or US
 subsidiaries of non-American companies.

 For more information, contact CBEMA, 311 First Street, NW, Suite 500,
 Washington, DC 20001-2178, Telephone: [phone].

 _C_O_D_A_S_Y_L_:__T_h_e__C_o_n_f_e_r_e_n_c_e__o_n__D_a_t_a__S_y_s_t_e_m_s__L_a_n_g_u_a_g_e_s

 The Conference on Data Systems Language (CODASYL) has been active since
 1960 in the development of the COBOL language, through its COBOL
 Committee (CC).  Since 1969, it also has been active in the development
 of a common Data Description Language for defining schemas and
 subschemas, and in a data manipulation language, through the DBTG Data
 Base Task Group of the CC.  The activities of the CC are documented in
 the COBOL Journal of Development, which serves as the official COBOL
 language specification.

 In 1969, ANSI (then the United States of America Standards Institute)
 issued the first COBOL standard.  At that time, the X3.4 committee stated
 that X3.4 recognizes the CODASYL COBOL Committee as the development and
 maintenance authority for COBOL.  In practice, this meant that ANSI
 agreed not to make any changes to the CODASYL-defined language
 specification.  Although this agreement has been challenged over the
 years, the CODASYL-ANSI agreement is still strong.  As a result, the
 CODASYL has enormous influence upon the COBOL language.

 Toward the end of 1971, a new CODASYL committee was established--the Data
 Description Language Committee (DDLC).  The DDLC was formed to serve the
 same functions for the schema DDL as the CC does for COBOL.  That is,
 since the schema DDL is a conceptual schema and network-model database
 language for use with many programming languages, not just COBOL, the
 DDLC continues the schema DDL development and publishes its own Journal
 of Development documenting the language's current status.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 282                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 The COBOL DML and subschema DDL (for defining an external view) of the
 DBTG are COBOL-specific and have remained part of the CC under the name
 ``The COBOL Data Base Facility.''

 The CODASYL membership is composed of voluntary representatives, mostly
 from computer manufacturers and users in industry and the US Federal
 government.

 _C_O_S_:__C_o_r_p_o_r_a_t_i_o_n__f_o_r__O_p_e_n__S_y_s_t_e_m_s

 COS is a US-based, international, nonprofit association of vendors and
 users, formed in 1985 to promote and accelerate the adoption of
 interoperable, multivendor products and services based on OSI and ISDN
 standards.  To accomplish its goals, COS provides a user-vendor forum for
 the statement of user requirements and the discussion and management of
 the issues surrounding the deployment of open systems.  COS also
 identifies test requirements, and sponsors test tools development and
 conformance and interoperability testing to verify that computer products
 and services conform to OSI or ISDN standards.

 COS's membership consists of more than 60 prominent manufacturer, user,
 and telecommunication service organizations worldwide.  COS cooperates
 with similar organizations such as SPAG Services in Europe and POSI in
 Japan.  Other key groups in the worldwide promotion, implementation and
 testing of OSI and ISDN standards are affiliated with COS under its
 Alliance Associate program.

 For further information, contact the Corporation for Open Systems, 1750
 Old Meadow Road, Suite 400, McLean, VA 22102-4306, USA, Telephone:
 [phone], Fax:  [phone].  In Europe contact Corporation for
 Open Systems, Avenue des Arts 1-2, bte 11, 1040 Bruxelles, Belgique,
 Telephone:  [phone], Fax:  [phone].

                                                                            e

 _E_P_R_I_:__E_l_e_c_t_r_i_c__P_o_w_e_r__R_e_s_e_a_r_c_h__I_n_s_t_i_t_u_t_e

 The Electric Power Research Institute's (EPRI) is an industry association
 concerned with electric power utilities.  Its membership comprises more
 than 673 publicly and privately owned utilities in the United States.
 Besides providing a variety of utility-specific services to its
 membership, EPRI's latest mission is to facilitate the use of open
 systems technology in the utility industry.

 Toward this end, EPRI has developed a Utilities Communication
 Architecture (UCA), which is similar to the National Institute for
 Standards and Technology's (NIST) Government Open Systems Interconnect
 Profile (GOSIP) Version 2.0.  Much of the UCA was developed by EPRI with
 the cooperation of Honeywell and Anderson Consulting.


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             283






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 EPRI's specific open system interests span realtime UNIX, expert systems,
 and database access using RDA and SQL.  Because of the financial
 structure of the utilities industry, EPRI wants to encourage these and
 other open systems technologies for equipment with a 12 to 15 year life
 cycle.

 For further information, contact EPRI's headquarters at 3412 Hillview
 Avenue, P.O.  Box 10412, Palo Alto, CA 94303, Telephone:  [phone].

 _E_S_P_R_I_T (_E_u_r_o_p_e_a_n _S_t_r_a_t_e_g_i_c _P_r_o_g_r_a_m_m_e _f_o_r _R_e_s_e_a_r_c_h _a_n_d _D_e_v_e_l_o_p_m_e_n_t _i_n
 _I_n_f_o_r_m_a_t_i_o_n _T_e_c_h_n_o_l_o_g_y)

 The European Strategic Programme for Research and development in
 Information Technology is a European research programme initiative,
 started in 1982 and sponsored by the Commission of the European
 Communities.  About 227 projects were implemented during the first phase
 of the project in five major work areas:  advanced microelectronics,
 software engineering and technology, advanced information processing,
 office automation, and computer integrated manufacturing.

 Nearly thirty projects have enabled substantial advances to be made in
 establishing internationally recognized standards.  Examples of the
 Portable Communications Tool Environment (PCTE) project, the
 Communication Network for Manufacturing Applications (CNMA) project, and
 the Herode project, which has prepared an Office Document Architecture
 standard for adoption as an ISO standard.

 The second phase of the Esprit programme will be concerned mainly with
 three areas--microelectronics and peripheral technologies; the creation
 of technologies and tools for the design of information processing
 systems; and enhancing the capacity for using and integrating information
 technology to extend the scope of its applications.

 For further information contact ESPRIT, Director General, DG XIII, CEC,
 rue de la Loi 200, B-1049 Brussels, Belgium, Telephone:
 (32 2) 235 11 11, and Telex:  21877 comeu b.

 _E_T_S_I_:__E_u_r_o_p_e_a_n__T_e_l_e_c_o_m_m_u_n_i_c_a_t_i_o_n_s__S_t_a_n_d_a_r_d_s__I_n_s_t_i_t_u_t_e

 The European Telecommunications Standards Institute (ETSI), founded in
 1988, is a voluntary standards organization involved in producing the
 telecommunications standards necessary to achieve a European unified
 market.  ETSI was established outside the CEN/CENELEC framework.  ETSI,
 however, works with CEN, CENELEC, and the European Broadcasting Union
 (EBU) in areas of mutual interest.

 ETSI's voting membership consists of postal administrations, along with
 manufacturers and trade associations, in each of the CEPT countries.
 Membership is not restricted to official representatives of member


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 284                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 countries.  The United States and US companies have been granted observer
 status.

 Standards approved by ETSI are voluntary standards known as ETS (European
 Telecommunications Standards).  ETSI also conducts prestandardization
 studies, develops technical reports and guidelines, holds conferences,
 workshops, seminars, and conducts interviews.  ETSI's interim standards
 are designated I-ETS.

 For further information, contact the European Telecommunications
 Standards Institute, B.P.  No.  52, F-06561 Valbonne CEDEX, France,
 Telephone:  [phone], Telex:  470 040 F, and Fax Number:
 (33 93) 65 47 16.

 _E_W_O_S_:__E_u_r_o_p_e_a_n__W_o_r_k_s_h_o_p__f_o_r__O_p_e_n__S_y_s_t_e_m_s

 The EWOS is an ongoing regional workshop, formed in 1987, to provide and
 coordinate European input to the international standard profiles process.
 It was formed as the result of an initiative of SPAG, in conjunction with  e
 CEN/CENELEC.                                                               e

 EWOS is the focal point in Europe for the study and development of OSI
 profiles and corresponding conformance test specifications.  EWOS
 documents have only to be submitted to public enquiry by CEN and CENELEC
 before becoming European norms.                                            e

 For further information contact European Workshop on Open Systems (EWOS),
 rue de Brederode 13, B-1000 Brussels, Belgium, Telephone:
 32 2 511 74 55.

                                                                            e

 _I_N_T_A_P (_I_n_t_e_r_o_p_e_r_a_b_i_l_i_t_y _T_e_c_h_n_o_l_o_g_y _A_s_s_o_c_i_a_t_i_o_n _f_o_r _I_n_f_o_r_m_a_t_i_o_n
 _P_r_o_c_e_s_s_i_n_g)

 The Interoperability Technology Association for Information Processing,
 in Japan, is a national agency, funded by MITI.  It deals with
 information technology, and specifically OSI products and advanced
 projects.  INTAP is developing and providing conformance testing tools
 and services in Japan in cooperation with POSI.

 _M_A_P/_T_O_P _U_s_e_r _G_r_o_u_p: (_M_a_n_u_f_a_c_t_u_r_i_n_g _A_u_t_o_m_a_t_i_o_n _P_r_o_t_o_c_o_l _a_n_d _T_e_c_h_n_i_c_a_l _a_n_d
 _O_f_f_i_c_e _P_r_o_t_o_c_o_l)

 The MAP Task Force was formed in 1980 by engineers from seven General
 Motors (GM) divisions, to identify a common OSI-based networking standard
 for plant-floor systems.  The Task Force grew to include all GM
 divisions, many other users, and many vendors.  Its specifications are
 known as Manufacturing Automation Protocol (MAP).


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             285






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 The MAP specifications mostly reference OSI standards, but they also draw
 on ANSI, IEEE, EIA, CCITT, and various industry standards.  Where
 standards do not exist, as in the case of the manufacturing messaging
 protocol, the MAP Task Force is either defining its own or instigating
 their formation by industry standards bodies.

 In 1984, the MAP Users Group was formed, under the auspices of GM, with
 the Society of Manufacturing Engineers as its Secretariat.  Its objective
 is to promote knowledge and use of MAP, and to insure input from users.

 In 1985, Boeing sponsored a similar effort to specify common networking
 protocols, known as the Technical and Office Protocols (TOP), for the
 engineering and business offices.  TOP is largely compatible with MAP,
 differing only at the lower two layers and the application layer where
 TOP addresses requirements of the technical and office user, rather than
 factory users.

 Later in 1985, a TOP Users Group was formed.  The entire effort became an
 international effort known as MAP/TOP, and the user group became the
 MAP/TOP User Group, which meets twice a year.

 Today, the MAP/TOP User Group is an independent, self-funded organization
 that represents thousands of users worldwide, tied together through a
 worldwide federation of MAP/TOP user groups.  Membership is open to
 either users or companies.  The Industry Cooperative Services (ICS) is
 the worldwide secretariat.  The MAP/TOP User Group also is a member of
 the Corporation for Open Systems (COS) and in North America, COS acts as
 the MAP/TOP User Group secretariat.

 The MAP/TOP User Group is a Requirements Interest Group (RIG) of the
 Corporation for Open Systems (COS).  This means that the MAP/TOP User
 Group generates requirements that vendors can use to built products.  COS
 serves as the coordinator between users and vendors.

 The MAP/TOP Task Force and User Group also is a major contributor of
 technical and conceptual ideas and specifications to the NIST, COS, and
 many of the IEEE POSIX Groups.

 For further information contact the World Federation of MAP/TOP Users
 Groups, P.O.  Box 1457, Ann Arbor, MI 48106, Telephone:  [phone],
 Fax:  [phone].  In North America, also contact the Corporation for
 Open Systems at 1750 Old Meadow Road, Suite 400, McLean, VA 22102-4306,
 Telephone: [phone], Fax:  [phone].

                                                                            e






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 286                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 _N_e_t_w_o_r_k__M_a_n_a_g_e_m_e_n_t__F_o_r_u_m

 A vendor-driven group, the Network Management Forum is chartered to
 produce a commonly agreed-upon specification subset of ISO's network
 management protocols and the command sets to implement this subset.  The
 promise of the NMF is that all of the network management products that
 its members come up with will conform to this common specification.

 The NMF itself will produce no products nor will it specify
 implementations.  Rather, the NMF will specify interfaces.

 Major vendors belong to the NMF from both the computer and                 e
 telecommunications industries.  The NMF has published Release 1 of its     e
 specifications (1990).  Member firms are developing products that conform
 to Release 1.

 NMF information may be had from the organization at 40 Morristown Road,
 Bernardsville, NJ 07924.  Telephone:  [phone].

 _N_P_S_C_:__N_a_t_i_o_n_a_l__P_r_o_t_o_c_o_l__S_u_p_p_o_r_t__C_e_n_t_e_r

 An Australian organization, the National Protocol Support Center was
 formed in 1986 as a joint effort between industry and the government.
 Like SPAG, COS, and POSI, the NPSC is promoting the adoption of OSI
 standards in information technology products and will be supporting a
 conformance testing capability in Australia.  The Australian government,
 however, provides approximately 50 percent of the NPSC funding.  For
 further information, contact (contact address and other information TBD).

 _O_b_j_e_c_t__M_a_n_a_g_e_m_e_n_t__G_r_o_u_p

 Founded in 1989 and headquartered in Framingham, MA, with marketing
 operations in Boulder, CO, the Object Management Group (OMG) is an
 international organization of more than 146 systems vendors, software
 developers and users.  The OMG was founded to promote the theory and
 practice of object management technology in the development of software.

 The OMG's goal is to develop a common framework, based on industry-
 derived guidelines, that is suitable for object-oriented applications.
 The adoption of this framework will make it possible to develop a
 heterogeneous applications environment across all major hardware and
 operating systems.

 The OMG members are quick to form a consensus on certain object
 management issues because they see these issues directly affecting their
 software sales.  For example, the OMG's object request broker design--key
 software needed to allow disparate open systems to request object
 services from remote sites--is supported by most major object-oriented     e
 software vendors.                                                          e


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             287






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Further information is available from the OMG at 492 Old Connecticut
 Path, Framingham, MA 01701.  Telephone:  [phone].

 _O_S_F_:__O_p_e_n__S_o_f_t_w_a_r_e__F_o_u_n_d_a_t_i_o_n

 The Open Software Foundation is a nonprofit, international consortium.     e
 Its goals include the development of software specifications and test      e
 suites for an open computing environment.                                  e

 OSF specifications are defined, and software developed, using an open
 process into which vendors and users have input and access.  The           e
 resulting AES specifications will be available in the public domain, and   e
 the software licensable, to OSF members and nonmembers, under identical    e
 terms.  Both members and nonmembers can also submit technologies to the    e
 OSF for consideration as an OSF specification and/or offering.  OSF's
 specifications and software will be based on the ISO/IEC 9945-1 core       e
 POSIX standard (POSIX.1 {2}), a variety of international, national, and    e
 industry standards and other consortia specifications.  The remainder of   e
 OSF software and specifications will be based on technologies contributed  e
 by numerous companies and universities as part of OSF's Request for        e
 Technology (RFT) process.                                                  e

 OSF active-participation membership is open to user organizations,         e
 computer hardware and software suppliers, government agencies,             e
 educational institutions, and other interested organizations worldwide.
 For further information, contact OSF at Eleven Cambridge Center,
 Cambridge, MA, Telephone:  [phone].  Alternatively, contact
 European headquarters at Open Software Foundation/Europe, Stefan-George-
 Ring 29, 8000 Munich 81, Germany, Telephone:  [phone], or Open
 Software Foundation/Japan, ABS Building, 2-4-16 Kudan Minami, Chiyoda-Ku,
 Tokyo 102, Japan, (81 3) 3 221 9770.

 _P_e_t_r_o_t_e_c_h_n_i_c_a_l__O_p_e_n__S_o_f_t_w_a_r_e__C_o_r_p_o_r_a_t_i_o_n                                   e

 Founded in October, 1990, the Petrotechnical Open Software Corporation     e
 (POSC) was started by BP Exploration, Chevron, Elf Aquitane, Mobil and
 Texaco to facilitate the development of integrated computing technology
 for the exploration and production (E & P) segment of the international
 petroleum industry.  Today, membership is open to all entities interested
 in the E & P industry.  These members include other petroleum companies,
 E & P service companies, software vendors, computer manufacturers, and
 research institutes.

 POSC's primary mission is the development of an industry-standard, open
 systems-based, software integration profile for E & P applications.  This
 platform will be the interface between petrochemical software
 applications, database management systems, workstations and users.  POSC
 activities focus on the development of an integrated E & P data model, a
 common look and feel user front-end, and a set of test suites enabling


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 288                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 developers to evaluate their offerings against selected industry
 standards.

 POSC is moving quickly and has sent out two public requests for inputs in
 several technical areas.  Project teams for base standards, the E & P
 data model, and data access are in place.  Staffing is in progress for
 other projects and special interest groups have been formed.  POSC
 offerings will be released to industry for production over the next few
 years.

 POSC is headquartered in Houston, TX at 10777 Westheimer, Suite 275,
 Houston, 77042.  Telephone:  [phone].

 _P_O_S_I_:__P_r_o_m_o_t_i_n_g__C_o_n_f_e_r_e_n_c_e__f_o_r__O_S_I

 The Promoting Conference for OSI was formed in Japan in November 1985 by
 six major computer manufacturers and the Nippon Telephone and Telegraph
 Corporation.  Its raison d'etre is to promote the adoption of OSI
 standards by cooperating with other international groups that have the
 same objective, such as the European-based SPAG and the US-based COS.
 But conformance testing in Japan is being developed and will be provided
 by the INTAP.

 For further information, contact (contact information TBD).

 _S_P_A_G_:__S_t_a_n_d_a_r_d_s__P_r_o_m_o_t_i_o_n__a_n_d__A_p_p_l_i_c_a_t_i_o_n__G_r_o_u_p

 The Standards Promotion and Application Group (SPAG), founded in 1983, is
 a nonprofit, international research and development consortium of about
 65 information technology manufacturers and users.  In 1986, it became a
 company registered under Belgian law as SPAG Services s.a.  SPAG's goals
 are to promote multivendor, interoperable products based on international
 standards, particularly OSI, and to keep its members informed about the
 latest developments in functional standards and conformance testing of
 products.

 To achieve its goals, SPAG plays a leading role in the European Workshop
 on Open Systems (EWOS), publishes the Guide to the Use of Standards (GUS)
 regularly, and participates in the development of International Standard
 Profiles (ISPs).  SPAG is particularly active in the development and
 marketing of test tools for manufacturing applications.  Through its
 SPAG-CCT efforts, (a collaboration of European organizations) which arose
 out of the ESPRIT Project 955, SPAG is developing, and will be providing,
 conformance test tools for testing MAP/TOP 3.0, and conformance testing
 services to industry.

 SPAG also is working within Europe to implement the certification
 infrastructure for OSI products, and is involved in a number of
 Conformance Test Services (CTS) projects within the Commission of


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             289






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 European Communities (CEC).  In addition, SPAG is active in
 Telecommunications areas and is leading a consortium developing
 verification services for the Broadband Networks project RACE.

 Twelve shareholder companies make up SPAG's board of directors.  The
 original founding companies--Bull, ICL, Nixdorf, Olivetti, Philips,
 Siemens, and STET--occupy seven seats on SPAG's twelve member board.  The
 shareholder membership was subsequently expanded to include Alcatel,
 British Telecom, Digital Equipment Corp., Hewlett-Packard, and IBM, who
 occupy the five remaining board seats.

 SPAG has close working relationships with its counterparts in North
 America (COS) and the Far East (POSI).

 For further information, contact Graham Knight, at SPAG Services s.a.,
 Standards Promotion and Application Group (SPAG), Avenue des Arts, 1-2
 bte 11, 1040 Brussels, Belgium, Telephone:  [phone], Fax
 32 2 210 08 00.

 _S_Q_L__A_c_c_e_s_s__G_r_o_u_p

 The SQL Access Group is a vendor group formed by a number of people in
 the ISO Remote Data Access (RDA) Group.

 The SQL Access Group's charter is several fold.  First, the Group is
 chartered to define a common subset of SQL functions to reconcile the      e
 many SQLs that exist.  The specifications will include an SQL data
 format, as well as protocols for moving data within a multivendor SQL
 environment.  Also included will be specifications for an enhanced SQL
 programming interface that will let developers write a single application
 that can access a variety of SQL databases.  These SQL Access
 specifications are scheduled to be published in late 1991.

 The SQL Access Group's second charter is to accelerate the work of the
 RDA group.  Third, the SQL Access Group is working on putting more
 distributed functionality into RDA.  Toward this end, each thing
 accomplished by the SQL Access group is fed back into the RDA group.

 For further information, contact the SQL Access Group at (Address TBD).

 _U_n_i_F_o_r_u_m                                                                   e

 UniForum is a nonprofit international association of open systems          e
 professionals.  Founded in 1980 as /usr/group, the association has,        e
 through its standards committees and technical committees, provided        e
 contributions to various standards and continues to be involved in the     e
 formal standards development process.  The specifications and standards    e
 to which UniForum has contributed include:                                 e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 290                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

     - The 1984 /usr/group Standard was contributed as a base document for  e
       the IEEE P1003.1 work.                                               e

     - The UniForum Technical Committee on Real Time meets jointly with     e
       the IEEE P1003.4 working group, working on the emerging POSIX        e
       realtime standards.                                                  e

     - The UniForum Technical Committee on Supercomputing evolved into the  e
       IEEE P1003.10 working group.                                         e

     - The UniForum Technical Committee on Transaction Processing evolved   e
       into the IEEE P1003.11 working group.                                e

     - The UniForum Technical Committee on Internationalization has         e
       contributed specifications to the IEEE P1003.1 and P1003.2 working   e
       groups and the ANSI X3J11 standard C committee and continues to be   e
       a technical resource for both formal and informal standards          e
       development bodies.                                                  e

 _U_N_I_X__I_n_t_e_r_n_a_t_i_o_n_a_l_/_U_N_I_X__S_y_s_t_e_m__L_a_b_o_r_a_t_o_r_i_e_s                                e

 UNIX International (UI) is a nonprofit industry organization formed to     e
 represent hardware manufacturers, system integrators, independent
 software vendors, value-added resellers, end-users, government agencies
 worldwide, industry standards bodies, and academic and research
 institutions who want to direct the evolution of System V UNIX and its     e
 corresponding specification, the _S_y_s_t_e_m _V _I_n_t_e_r_f_a_c_e _D_e_f_i_n_i_t_i_o_n (SVID).     e
 It has since expanded its scope to provide a framework for UNIX-based      e
 open systems work in the areas of desktop computing, corporate hub
 computing, distributed computing, and an enterprise-wide framework known   e
 as ``Atlas.''                                                              e

 Unlike X/Open, OSF, AT&T, and the IEEE, UI does not produce
 specifications, software, or standards.  Its functions range from
 specifying technical and timing requirements for future System V versions
 and making suggestions about specific function designs to influencing
 AT&T UNIX licensing policies.

 Using its ``one-member, one-vote'' approach, UI members formulate a
 consensus regarding the requirements and technical specifications for new
 System V UNIX versions.  UI delivers its requirements to UNIX System
 Laboratories (USL), the AT&T spinoff that develops, distributed, and
 licenses UNIX.  UI is USL's primary input source on technical
 requirements, conformance, and timing of releases.  USL is committed to
 implement software to satisfy UI's requirements, unless there is a reason
 not to.

                                                                            e



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             291






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 For further information, contact UNIX International, Waterview Boulevard,
 Parsippany, NJ 07054, [phone] or [phone].  In Europe,
 contact UNIX International, Avenue de Beautieu 25, 1160 Brussels,
 Belgium, (32-2-672-3700).  In the Asian Pacific region, contact
 Karufuru-Kanda Bldg.  8F, 1-2-1 Kanda Suda-cho, Chiyoda-du Tokyo 101,
 Japan, (81) 3-5256-6959.

 _U_s_e_r__A_l_l_i_a_n_c_e__f_o_r__O_p_e_n__S_y_s_t_e_m_s

 The User Alliance for Open Systems was formed from two informal
 organizations (the Atlanta 17 and the Houston 30).  The Alliance is
 currently a Requirements Interest Group (RIG) of the Corporation for Open
 Systems International (COS).

 The Alliance is dedicated to overcoming barriers to open systems and
 speeding the development and deployment of open systems products.  It
 intends to act as a catalyst toward the development and use of open
 systems.  It will develop no specifications or products.  Rather, the
 Alliance will create and support processes to influence and accelerate
 the availability of open systems technology (e.g., a repository of
 information about the cost benefits of open systems).

 In 1990 the organization began its work by identifying barriers to open
 systems and global actions to eliminate those barriers.  In 1991 the
 organization intends to start bringing resources to bear to achieve its
 goals.  The Alliance has had one formal meeting (Dallas, March 1991) and
 will have its second formal meeting in McLean, Virginia in Nov.  1992.
 Alliance committee work is ongoing throughout this period with three
 major subgroups in the formative stages.

 For further information, contact the Corporation for Open Systems, 1750
 Old Meadow Road, Suite 400, McLean, VA 22102-4306, Telephone:
 [phone].

 _X_._4_0_0__A_P_I__A_s_s_o_c_i_a_t_i_o_n

 The X.400 API (Application Programming Interface) Association is an
 industry association formed initially to bring X.400 messaging into the
 PC LAN world.  There are more than twenty companies in the association,
 and they include most of the current X.400 players.

 Among its activities, the X.400 API Association developed an X.400
 Application Programming Interface specification in conjunction with
 X/Open.  These interfaces, completed in September 1990, are jointly owned
 by the X.400 API Association and X/Open.  The two organizations
 contributed these interface specifications to the P1224 Group to use as a
 basis for the P1224 standard.




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 292                                C Standards Infrastructure Description






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 For further information contact (Address and other contact information:
 TBD)

 _X_/_O_p_e_n

 X/Open is an independent, nonprofit consortium formed in 1984.  Its goals  e
 are to determine user and market requirements and to specify a complete,   e
 source-level-portable application environment and test suites.  Although   e
 its members were initially vendors, X/Open's membership now encompasses
 users, system integrators, value-added resellers, government agencies
 worldwide, other industry-standards groups, and academic and research
 institutions.

                                                                            e

 The X/Open environment includes specifications for an operating system
 interface, networking, data management, programming languages, floppy
 disk formats, internationalization, and distributed transaction
 processing.  The X/Open Group does not normally define standards for
 these areas.  Instead, it chooses from existing and emerging standards.    e
 An X/Open market research program and open user requirements congress      e
 identify and prioritize user and market requirements, based on input       e
 solicited from users.  These prioritized requirements are published in a   e
 document known as the _O_p_e_n _S_y_s_t_e_m_s _D_i_r_e_c_t_i_v_e.  These prioritized           e
 requirements also help drive the X/Open specification process.  The        e
 X/Open specifications are published in a series of books known as the      e
 X/Open Portability Guide.                                                  e

 The X/Open environment is based on the ISO/IEC 9945-1 core POSIX           e
 (POSIX.1 {2}) standard, parts of AT&T's System V Interface Definition      e
 (SVID), and formal international standards that are already accepted or    e
 likely to be accepted.  However, to rapidly get standards into the field
 for practical use, where no formal standards exist, X/Open specifies
 industry standards and widely-accepted de facto standards (including some
 based on real-world products that have achieved consensus in the
 marketplace).  In some instances where neither formal nor de facto
 specifications exist but there is a strong need for standards (e.g.,
 internationalization and transaction processing), X/Open has itself
 defined specifications.

                                                                            e
 For further information, contact X/Open Company Ltd.  at Apex Plaza,
 Forbury Road, Reading, Berkshire, RG1 1AX, UK, Telephone: [phone].
 In the US, contact X/Open at 1010 El Camino Real, Menlo Park, CA 94025,
 Telephone: [phone].






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 C.3 Related Organizations                                             293








































































                                                               P1003.0/D14






                                  Annex D
                               (informative)
                              Electronic-Mail




 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _K_e_v_i_n _L_e_w_i_s

 The following table lists currently-known e-mail addresses for active
 working group members.  To correct your entry, send e-mail directly to
 Hal Jespersen, listed below.

 Michelle Aden      Sun Microsystems      [e-mail]
 Carolyn Baker      MITRE                 [e-mail]
 Timothy Baker      Ford Aerospace
 Ralph Barker       UniForum              [e-mail]       e
 Rich Bergman       NOSC                  [e-mail]
 Andy Bihain        GTE Telops            [e-mail]                e
 Jacques Cazier     Mitre                 [e-mail]                  e
 Bud Conrad         Tandem                [e-mail]             e
 Joseph Cote        Treasury Board        tbsitm@nrcvm01                    e
                       of Canada
 Bernard Cox        NASA JSC
 Francis Deckelman  US Navy               [e-mail]               e
 Matt Einseln       Datafocus                                               e
 Don Folland        CCTA                  [e-mail]
 David Folsom       CDC                   [e-mail]                  e
 Thomas Ford        USAF                  [e-mail]
 Bob Gambrel        Unisys                [e-mail]
 Al Hankinson       NIST/NCSL             [e-mail]
 E. Lee Hutchins    USAF                  [e-mail]         e
 Jim Isaak          DEC                   [e-mail]
 Petr Janecek       X/Open                [e-mail]
 Astrid Jeffries    Unisys                [e-mail]            e
 Hal Jespersen      POSIX Software Group  [e-mail]
 Lorraine Kevra     AT&T                  [e-mail]
 Ruth Klein         AT&T                  [e-mail]
 Doris Lebovits     AT&T                  [e-mail]
 Kevin Leininger    Fermilab              [e-mail]              e
 Kevin Lewis        DEC                   [e-mail]
 Heinz Lycklama     Interactive Systems   [e-mail]




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Annex D Electronic-Mail                                               295






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Randolph Lynwood   NASA
 Doug MacDonald     General Electric
 Roger Martin       NIST                  [e-mail]
 Dick McNaney       SAIC                  [e-mail]
 Pete Meier         IBM                   ...uunet!aixsm!meier
 Howard Michel      USAF                  [e-mail]        e
 Gary Miller        IBM                   ...uunet!aixsm!miller             e
 Kevin Murphy       BT                    [e-mail]        e
 Mary Lynne Nielsen IEEE                  [e-mail]
 Patricia Oberndorf NADC                  [e-mail]
 Jim Oblinger       NUSC                  [e-mail]        e
 Pat Patterson      NASA                  [e-mail]
 David Pruett       NASA JSC              [e-mail]
 Wendy Rauch        Emerging Technologies ...uunet!etg!wrauch
                       Group
 Lynwood Randolph   NASA HQ               [e-mail]        e
 Brad Reed          EDS                   [e-mail]
 Gregory Sawyer     Space & Naval Warfare                                   e
                       Systems Command                                      e
 Carl Schmiedekamp  NADC                  [e-mail]
 Fritz Schulz       OSF                   [e-mail]
 Richard Scott      Chemical Abstracts    uunet!osu-cis!chemabs!rls27
                       Service
 Glen Seeds         Systemhouse
 Charles Severance  Mich. State Univ.     [e-mail]
 Lewis Shannon      NCR                   [e-mail]
 Peter Smith        DEC                   [e-mail]
 Keith Stobie       Tandem                [e-mail]           e
 Sandra Swearingen  USAF                  [e-mail]
 Jong Sung Sunwoo   NCA                                                     e
 Marti Szczur       NASA/GSFC             [e-mail]
 Ravi Tavakley      CDC                   [e-mail]          e
 Martial Van Neste  CGI Group             [e-mail]
 Robert Voigt       Space & Naval Warfare [e-mail]
                       Systems Command
 Gentry Watson      UNIX Int'l            [e-mail]
 Alan Weaver        IBM                   ...uunet!aixsm!weaver
 John Wilbur                                                                e
 John Williams      GM-CPC Hdqts.         [e-mail]                e
 Arnold Winkler     Unisys                [e-mail]            e
 George Zerdian     Hughes                [e-mail]










              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 296                                                     D Electronic-Mail






                                                               P1003.0/D14






                                  Annex E
                               (informative)
                            Additional Material




 E.1  Software Development Environments

 _R_e_s_p_o_n_s_i_b_i_l_i_t_y:  _D_o_n _F_o_l_l_a_n_d


 E.1.1  Overview and Rationale

 Software Development Environments are dealt with as a particular
 application area needing special attention for the following reasons:

     - The domain of Software Development Environments is one of prime
       importance.  Software development is a major area of expenditure
       for government and large commercial organizations.

     - The need for standardization is being driven not only by the SDE
       vendors and users, but also by the Independent tool developers who
       want to get their tool products on as many vendor platforms as
       possible.

     - The SDE domain calls not only for portability, but also for
       particular integration and interoperability requirements.

     - The domain is primarily of interest to that user community that has
       large complex software development requirements, but it is also of
       interest to all application areas as software development is an
       enabling technology for all applications.

 Software engineers seek more powerful assistance to improve productivity
 and quality in the software development process.  Considered opinion
 currently favors Project Support Environments (PSE) underpinned in such a
 way that the facilities are capable of being implemented on different
 machines.  A PSE needs a base holding information such as specifications,
 designs, code, schedules, configuration plans, tests, etc., to support
 the developers.  The interface between the base and the tools must ensure
 portability of the tools.  Again, these tools will be supported by
 relevant language standards.



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 E.1 Software Development Environments                                 297






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 Certain design methodologies themselves have been modeled formally to
 establish their degree of rigor and self-consistency.  Function Point
 Analysis is one method of measuring software systems and computing
 productivity that is increasing in use.  It measures inputs, outputs, and
 entities accessed to determine transaction size; it gauges technical
 complexity by reference to 19 characteristics.  These are combined to
 give a measure of systems size.  Productivity is the ratio of system size
 in function points to the effort required to produce or maintain the
 system.

 Generally, software support for the development process is in its infancy
 and effective metrics have not yet been developed.


 E.1.2  Scope

 The problem domain is complex software development, from the generation
 of an idea to the delivery and ongoing support of a solution product set.

 Thus, an SDE may include some or all of the following:

     (1)  Software Development Life Cycle

           (a)  Requirements analysis

           (b)  Logical design

           (c)  Physical design

           (d)  Functional and interface specification

     (2)  Activity support

           (a)  Prototyping

           (b)  Program development and testing

           (c)  Quality assurance and regression testing

           (d)  Generation of user documentation

           (e)  User training

           (f)  Problem report tracking and maintenance

           (g)  Maintenance and tracking of schedules

     (3)  Configuration Management



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 298                                                 E Additional Material






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

           (a)  Automatic version management

           (b)  Integrity management

           (c)  Traceability

     (4)  Project Management

     (5)  Data Administration

           (a)  Access control

 In the context of developing software for a POSIX Open System
 Environment, design will take account of portability and interoperability
 requirements.  The SDE tools themselves should be portable.  The software
 development activities may be provided with a large set of tools and
 applications.  The SDE must provide the necessary support for the
 integration of all of these tools.


 E.1.3  Reference Model

 _________________________________________________________________________



















 _________________________________________________________________________
                 Figure E-1  -  Software Development Model


 In this clause the conceptual view of software development is related to
 the POSIX Reference Model (Figure 3-1).  The software developer's view is
 shown in Figure E-1.  The tools used to develop software can be viewed as


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 E.1 Software Development Environments                                 299






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 _________________________________________________________________________
















 _________________________________________________________________________
            Figure E-2  -  Software Development Reference Model


 applications in their own right in the context of the POSIX Reference
 Model, requiring the same services from the platform as for Database
 Management.

 In the Software Development Model, the Environment Adaptation and Project
 Support Tools ``layer'' provides the essential link between the
 programmer, designer or analyst, the design method, and the development
 infrastructure.  At this level are provided the tools and applications
 that are unique to the project or methodology; e.g., project management
 workbench.  It requires support from a consistent human-computer
 interface to the Functional Tools.

 The Functional Tools and Integration Mechanisms embrace the essential
 tool set to enable software developers to build software.  It includes
 simple tools such as editors, tools for tool-building, and integration
 mechanisms.  There will be tools for Configuration Management, Version
 Management, and System Administration.  It is not within the scope of
 this guide to discuss these in detail.

 The whole software development environment is underpinned by essential
 management systems, such as object management system, a data dictionary,
 a user interface management system, and environment management.  A
 database will frequently be established to hold specifications, designs,
 configuration plans, etc.

 In the POSIX Open System Environment, the software development model can
 be incorporated into the POSIX Reference Model as in Figure E-2.  The
 model shows that the tools and services required by the software


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 300                                                 E Additional Material






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 developer are part of the POSIX Open System Environment and are available
 through the POSIX OSE API.


 E.1.4  Services Requirements

 Software developers, i.e., designers, analysts, and programmers, use
 software applications to facilitate the complex task of software
 development.  A tool will require services from the application platform
 and will frequently require support from another application in the
 application set.  There are many possible implementations of tool sets.
 Descriptions of these are beyond the scope of this guide.

 E.1.4.1  Application Program Interface Services

 The services required at the API are essentially similar to those
 described for Database Management in 4.4.4.1; i.e., Data Definition and
 Manipulation, Data Access, Data Integrity, and such Miscellaneous
 Services as Data Dictionary.

 E.1.4.2  External Environment Interface Services

 A consistent human-computer interface to the tool set is required.  Some
 of the programmer's tool set will be explicitly focused on windowing
 services (such as 4.7 and 4.8) and provide assistance to develop software
 with improved usability.

 Resource data formats must be specified in order to ensure effective
 information interchange [for example, CASE Data Interchange Format
 (CDIF)], for which standards are currently under development under the
 aegis of the CDIF Technical Committee (see also E.1.5.2 and 4.5).

 Protocol services are required for the transport of data (see 4.3).

 E.1.4.3  Interapplication Software Entity Services

 Many of the tools depend for interface between one another upon the data
 dictionary/repository, which is a key software component and which may
 conceptually be regarded as part of the Applications Platform.  Included
 in this category will be utilities for servicing the DBMS, such as
 recovery, reorganization, and restructure:

     - Object management system

     - User interface management system

     - Database management system




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 E.1 Software Development Environments                                 301






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

     - Transaction processing management system

 Details of these management systems may be recorded in the data
 dictionary/repository.

 E.1.4.4  Software Development Resource Management Services

 These services are generally not visible to the programmer or software
 developer at the Tools API, usually being provided by the tool building
 and other software development utilities.


 E.1.5  Standards, Specifications, and Gaps

 This subclause describes current accepted standards that are relevant to
 this area in addition to the language standards in 4.1.5 and the database
 standards in 4.4.5.


               Table E-1  -  Software Development Standards
 __________________________________________________________________________________________________________________________________________________
                        Service                       SpecificationSubclause
 ___________________________________________________________________________

 Miscellaneous Services:

     Labeling of magnetic tape                        ISO 1001     4.11.5.?
     Labeling of cassette and cartridge               ISO 4341     4.11.5.?
     Labeling of flexible disks                       ISO 7665     4.11.5.?
     Volume and file structure for flexible disks     ISO 9293     4.11.5.?
     Volume and file structure for CD-ROM             ISO 9660     4.11.5.?
     Documentation symbols and flowchart conventions  ISO 5807     4.11.5.?
     Documentation of applications                    ISO 6592     4.11.5.?
     Program flow for sequential files                ISO 6593     4.11.5.?
     Data descriptive file for information interchangeISO 8211     4.11.5.?
     Program constructs and conventions               ISO 8631     4.11.5.?
     User documentation                               ISO 9127     4.11.5.?
 __________________________________________________________________________________________________________________________________________________


 E.1.5.1  Current Standards

 This subclause briefly identifies the current standards in this area.

 _T_h_e _f_o_l_l_o_w_i_n_g _p_r_o_v_i_d_e_s _p_l_a_c_e _h_o_l_d_e_r_s _f_o_r _f_u_r_t_h_e_r _t_e_x_t _t_o _b_e _i_n_s_e_r_t_e_d -
 _a_s_s_i_s_t_a_n_c_e _r_e_q_u_i_r_e_d _p_l_e_a_s_e.





              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 302                                                 E Additional Material






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 E.1.5.1.1  International Standards

 _L_a_b_e_l_i_n_g__a_n_d__F_i_l_e__S_t_r_u_c_t_u_r_e__o_f__M_a_g_n_e_t_i_c__M_e_d_i_a

 The following standards refer to the labeling of magnetic media and for
 the file structure on such media to facilitate information interchange:

       Labeling of magnetic tape                           ISO 1001
       Labeling of cassette and cartridge                  ISO 4341
       Labeling of flexible disks                          ISO 7665
       Volume and file structure for flexible disks        ISO 9293
       Volume and file structure for CD-ROM                ISO 9660
       Data descriptive file for information interchange   ISO 8211

 _T_h_e _a_b_o_v_e-_m_e_n_t_i_o_n_e_d _s_t_a_n_d_a_r_d_s _m_i_g_h_t _b_e _m_o_r_e _s_u_i_t_a_b_l_y _c_a_l_l_e_d _o_u_t _i_n
 _R_i_c_h_a_r_d _S_c_o_t_t'_s _s_e_c_t_i_o_n _4._5.

 _S_o_f_t_w_a_r_e__D_o_c_u_m_e_n_t_a_t_i_o_n

 There are several standards dealing with documentation to assist with the
 task of software development, and therefore potentially facilitating
 programmer and designer portability, as well as user documentation.

            Documentation symbols and conventions      ISO 5807
            for data, program and system flowcharts,
            program network charts, and system
            resources charts
            Guidelines for the documentation of        ISO 6592
            computer-based application systems
            Program flow for processing sequential     ISO 6593
            files in terms of record groups
            Program constructs and conventions for     ISO 8631
            their representation
            User documentation and cover information   ISO 9127
            for consumer software packages

 E.1.5.1.2  Regional Standards

 ECMA has approved ECMA-149 as the standard for the Portable Common Tool
 Environment (PCTE).

 E.1.5.1.3  National Standards

 _T_o _B_e _P_r_o_v_i_d_e_d







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 E.1 Software Development Environments                                 303






 P1003.0/D14                               GUIDE TO THE POSIX OPEN SYSTEMS

 E.1.5.2  Emerging Standards

 This subclause describes the activities currently in progress to further
 standardize this area.

 E.1.5.2.1  International Standards

 _T_o _B_e _P_r_o_v_i_d_e_d

 E.1.5.2.2  Regional Standards

 _T_o _B_e _P_r_o_v_i_d_e_d

 _C_A_S_E__D_a_t_a__I_n_t_e_r_c_h_a_n_g_e__F_o_r_m_a_t__(_C_D_I_F_)

 The CDIF Technical Committee is developing a data interchange format to
 serve as an industry standard for exchanging information between
 Computer-Aided Software Engineering (CASE) tools.  CDIF is an EIA-
 endorsed initiative.  It assumes that two or more tools may interface
 asynchronously with each other and will transfer information from one to
 another via ``CDIF files.''  The types of information that may be
 contained in these files is defined by the CDIF Conceptual Models.

 _P_o_r_t_a_b_l_e__C_o_m_m_o_n__T_o_o_l__E_n_v_i_r_o_n_m_e_n_t__(_P_C_T_E_)

 ECMA TC33 has responsibility for the development and maintenance of PCTE.
 The committee formed a Task Group in 1988 to develop a Reference Model
 which would assist the standardization process.  Such a model has been
 developed totally independent of PCTE, and is described in ECMA Technical
 Report 55.  The model provides a way to describe, compare, and contrast
 CASE environment frameworks.

 E.1.5.2.3  National Standards

 _T_o _B_e _P_r_o_v_i_d_e_d

 E.1.5.2.4  National Standards

 _T_o _B_e _P_r_o_v_i_d_e_d

 E.1.5.3  Gaps in Available Standards

 E.1.5.3.1  Public Specifications

 _T_o _B_e _P_r_o_v_i_d_e_d






              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 304                                                 E Additional Material






 ENVIRONMENT INTERIM DOCUMENT                                  P1003.0/D14

 E.1.5.3.2  Unsatisfied Service Requirements

 _T_o _B_e _P_r_o_v_i_d_e_d


 E.1.6  OSE Cross-Category Services

 Not applicable.


 E.1.7  Related Standards

 _T_o _B_e _P_r_o_v_i_d_e_d


 E.1.8  Open Issues

     - Relationship between methodology and formats

 [_P_C_T_E _a_n_d _C_A_I_S-_A _h_a_v_e _b_e_e_n _m_o_v_e_d _h_e_r_e _l_a_r_g_e_l_y _b_e_c_a_u_s_e _i_t _i_s _n_o_t _c_l_e_a_r
 _w_h_a_t _t_o _d_o _w_i_t_h _t_h_e_m.  _T_h_e_y _a_r_e _n_o_t _a_d_e_q_u_a_t_e_l_y _a_c_c_o_m_m_o_d_a_t_e_d _b_y _t_h_i_s
 _m_o_d_e_l.  _T_h_e_y _a_r_e _b_o_t_h _h_y_b_r_i_d_s _o_f _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m _a_n_d _d_a_t_a_b_a_s_e _m_a_n_a_g_e_m_e_n_t
 _s_y_s_t_e_m _c_a_p_a_b_i_l_i_t_i_e_s _t_h_a_t _s_e_e_m _t_o _b_e_l_o_n_g _e_i_t_h_e_r _e_v_e_r_y_w_h_e_r_e _o_r _n_o_w_h_e_r_e.
 _T_h_e_y _c_o_u_l_d _b_o_t_h _w_e_l_l _b_e _u_s_e_d _i_n _c_o_n_j_u_n_c_t_i_o_n _w_i_t_h _a _P_1_0_0_3._1
 _i_m_p_l_e_m_e_n_t_a_t_i_o_n, _b_u_t _t_h_e_y _c_o_u_l_d _a_l_s_o _b_e _i_m_p_l_e_m_e_n_t_e_d _o_n _o_t_h_e_r _b_a_s_e
 _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m_s, _o_r _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s _c_o_u_l_d _e_v_e_n _e_x_p_a_n_d _t_h_e_i_r
 _c_a_p_a_b_i_l_i_t_i_e_s _t_o _p_r_o_v_i_d_e _f_u_l_l _o_p_e_r_a_t_i_n_g _s_y_s_t_e_m_s.  _P_1_0_0_3._0 _m_u_s_t _d_e_c_i_d_e _w_h_a_t
 _t_o _d_o _w_i_t_h _t_h_e_m.]

 _P_C_T_E

 An effort by the European Computer Manufacturers Association (ECMA) has
 resulted in the definition by Technical Committee 33 of the Basis for the
 Portable Common Tools Environment (PCTE).  This is now an ECMA standard
 and is referred to as Standard ECMA-149.

 _C_A_I_S_-_A

 MIL-STD-1838A (CAIS-A) was developed by the US Department of Defense to
 provide a common foundation for Ada Programming Support Environments.
 Similar in nature to PCTE (see above), it too covers many of the system
 services covered by 4.2.4.  In addition, it provides data management
 services such as those discussed in 4.4 and data interchange services
 (specifically, a Common External Form) similar to those discussed in 4.5.







              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 E.1 Software Development Environments                                 305








































































                                                               P1003.0/D14

                         Alphabetic Topical Index



 A                                      Application Platform
                                           Implementation Considerations
 Abbreviations  ... 13                      ... 33
 ABS  ... 288                           application platform
 Accounting  ... 221                       definition of  ... 7
 ACID  ... 119, 122, 126                Application Program Interface
 ACL  ... 141, 212                         (API) Elements  ... 135
 ACSE  ... 95                           Application Program Interface
 AD1  ... 91                               (API)  ... 20, 25
 Ada  ... 46, 48                        application program interface
 Administration  ... 175                   (API)
 AEP  ... 7, 228                           definition of  ... 7
 AES  ... 64, 69, 185, 288              Application Program Interface
 AFNOR: Association Francaise de           Services  ... 55, 83, 103, 113,
    Normalization  ... 268                 124, 136, 158, 172, 179
 AFNOR  ... 268                         Application Program Interface
 Alphabetic Topical Index  ... 307          ... 24
 ANSI: American National Standards      Application Program Services
    Institute  ... 268                      ... 45
 ANSI X3.122  ... 115-116               Application Programming Interface
 ANSI X3.133  ... 107                      Services  ... 212
 ANSI X3.135  ... 130                   Application Software Elements
 ANSI X3.138  ... 106, 108                  ... 135
 ANSI X3.168  ... 106, 130              application software entities
 ANSI/ISO  ... 159                          ... 25
 ANSI  ... 48-50, 107-109, 115-116,     application software
    129, 145-146, 151, 159, 163-           definition of  ... 7
    168, 234, 243, 245, 263, 268-       Application to Application Service
    269, 271-272, 275-276, 278-279,         ... 84
    282, 286, 291                       Application to System Services
 API Service Requirements  ... 198          ... 84
 API                                    application
    definition of  ... 13                  definition of  ... 7
 APL  ... 46, 48                        APP  ... 278
 APL  ... 45-46, 48, 128, 162, 280      Approved POSIX Standardized
 Application Environment Profile           Profiles  ... 237
    (AEP)                               APT  ... 280
    definition of  ... 7                ASCE  ... 80, 91
 Application Platform Decomposition     ASCII  ... 192
    III - Redirection  ... 36           ASE  ... 95
 Application Platform Decomposition     ASN.1  ... 91, 96, 110, 115, 117,
    II - Layering  ... 36                  207
 Application Platform                   AT&T  ... 69, 185, 291, 293
    Implementation - Subdivision
     ... 35


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              307






 P1003.0/D14

 B                                      CCR  ... 130
                                        CCR  ... 110, 130
 background  ... 2, 6, 120, 182,        CDIF  ... 115, 117
    195, 257                            CEC  ... 284, 290
 base standard                          CEDEX  ... 285
    definition of  ... 7                CEN/CENELEC/CEPT  ... 270
 Base Standards Working Groups          CEN/CENELEC/CEPT  ... 270
     ... 254                            CEN/CENELEC  ... 284-285
 Basic Terminology  ... 228             CENELEC  ... 270-271, 284-285
 Basic Window Services  ... 137         CENLEC  ... 271
 BASIC  ... 46, 49-50                   CEN  ... 266, 270-271, 284-285
 BASIC  ... 45-46, 48-50, 128, 162,     CEPT  ... 270-271, 284
    263                                 CGI  ... 151, 159, 162, 164-165
 Basis for This Guidance  ... 231       CGM  ... 115-116, 151, 159, 165,
 Bibliography  ... 262                     243
 B.P  ... 285                           CGRM  ... 151-152, 159, 167
 BSD  ... 66, 183, 185                  CH-1211  ... 2, 262
 BSI: British Standards Institute       Character Sets and Data
     ... 269                               Representation  ... 114, 192
 BSI  ... 269                           Character-based Terminal Reference
 built-in  ... 178                         Model  ... 172
                                        Character-Based User Interface
                                           Services  ... 171
 C                                      Clear Communications  ... 234
                                        C-LISP  ... 128, 162
 C Standard  ... 146, 174, 276          CMA  ... 213
 C  ... 47, 49                          CMDB  ... 216
 C++  ... 50                            CNMA  ... 284
 CAD/CAM/CAE  ... 152                   COBOL  ... 47, 49
 CAD/CAM  ... 131                       COBOL  ... 22, 27, 44-45, 47-49,
 CAD  ... 47, 117                          106, 128, 162, 243, 245, 254,
 Canadian Standards Association            280, 282-283
    (CSA)  ... 269                      CODASYL: The Conference on Data
 Capability and Security Services          Systems Languages  ... 282
     ... 70                             CODASYL-ANSI  ... 282
 Capacity Management  ... 222           CODASYL  ... 107, 282-283
 CASE Data Interchange Format           Coherence  ... 235, 254
    (CDIF)  ... 117                     Common LISP  ... 47
 CASE  ... 117, 135                     Communication EEI Elements  ... 76
 CBEMA: Computer and Business           Communications Interface
    Equipment Manufacturers                definition of  ... 7
    Association  ... 282                Communications Services API
 CBEMA  ... 279, 281-282                    ... 26
 CCITT: Comite Consultatif              Communications Services  ... 25
    International de Telegraphie et     Completeness  ... 233
    Telephonie  ... 270                 Computer Graphics Metafile (CGM)
 CCITT  ... 91, 95, 200, 202-203,           ... 116
    213, 262, 266, 270, 272, 275,
    278, 286


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 308                                              Alphabetic Topical Index






                                                               P1003.0/D14

 Computer Graphics Reference Model      D
    Level Structure  ... 153
 Configuration Management  ... 175      DAC  ... 212
 Conformance to a POSIX SP  ... 255     Data Access Services  ... 104
 Conformance  ... 3, 254                Data Definition and Manipulation
 conformance  ... 3, 43, 150, 152,         Services  ... 103
    159, 166, 210, 230-233, 246,        Data Description Protocols
    249, 252, 254-255, 260, 269,            ... 114
    278, 283, 285, 287, 289, 291        Data Format Protocols  ... 114
 Considerations for Developers of       Data Integrity Services  ... 104
    POSIX SPs  ... 249                  Data Interchange Reference Model
 Content of the Multiprocessing             ... 112
    Systems Profile  ... 240            Data Interchange Services  ... 111
 Content of the Platform                Data Interchange Standards
    Environment Profile  ... 239            ... 115
 Content of the Supercomputing          Data Representation Services
    Profile  ... 242                        ... 88
 Content of the Transaction             Data Transfer and Connectivity
    Processing Profile  ... 244             ... 89
 Conventional Transaction               Database Administration Services
    Processing Model  ... 121               ... 105
 Conventional Transaction               Database API  ... 100
    Processing Reference Model          Database Manager  ... 100
     ... 121                            Database Recovery Services
 Conventions  ... 5                         ... 105
 Coordinate Systems and Clipping        Database Resource Management
     ... 156                               Services  ... 105
 COS: Corporation for Open Systems      Database Services  ... 99
     ... 283                            Database Standards  ... 107
 COS  ... 283, 286-287, 289-290,        Database Utility Program  ... 100
    292                                 DBSSG  ... 109
 CPIC  ... 91                           DBTG  ... 282-283
 CPIO  ... 67                           DCT  ... 262
 CPU  ... 56-57, 242                    DDLC  ... 282
 C++  ... 45, 47-48, 50                 DDL  ... 107, 282-283
 CRT  ... 25                            Definitions  ... 5
 CSA  ... 269                           definitions  ... 7
 CSA-Z243  ... 200, 205                 Detailed Guidance to Profile
 CSMA/CD  ... 91, 277                      Writers  ... 232
 CSS  ... 165                           Detailed Network Service
 CTS  ... 289                              Requirements  ... 87
 Cultural Conventions  ... 195, 198     Dialog Services  ... 143
 Current Standards  ... 48, 65, 91,     DIN: Deutsches Institut fur
    106, 115, 128, 145, 159, 174,          Normung  ... 271
    183, 200, 213                       DIN  ... 196, 271-272
 Curses  ... 175                        Directory Services Architecture
                                            ... 83




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              309






 P1003.0/D14

 Directory Services  ... 83                178-180, 213
 directory  ... 60-61, 67, 70, 73-      EFTA  ... 270
    75, 80, 82-83, 91, 95-96, 127,      EIA: Electronic Industries
    130, 181-182, 184, 213, 284,           Association  ... 276
    290                                 EIA  ... 91, 117, 276, 286
 DIS  ... 50, 130, 159, 163-164,        Electronic Data Interchange (EDI)
    166, 200, 234, 266                      ... 116
 Distributed Database Management        Electronic-Mail  ... 295
    Services  ... 106                   Embedded Realtime Systems  ... 246
 Distributed System Configuration       Emerging Standards  ... 50, 68,
    Management  ... 217                    91, 108, 116, 128, 145, 165,
 Distributed System Environment            174, 184, 204, 214
    Model  ... 29                       _e_n_v_i_r_o_n  ... 67
 Distributed System Services            Environment Services  ... 58
     ... 88                             ENV  ... 266, 271
 DML  ... 107, 283                      EPRI: Electric Power Research
 DNI  ... 81-82, 91, 95                    Institute  ... 283
 document  ... 2, 5-8, 11-12, 21,       EPRI  ... 283-284
    29, 31, 41, 43, 66, 96, 102-        _e_r_r_n_o  ... 67
    103, 115-116, 126, 131, 146,        Error Handling  ... 139
    159, 197, 199, 206-207, 210,        ESPRIT (European Strategic
    213, 220, 227-228, 231-235,            Programme for Research and
    238-239, 241, 249, 251, 253,           Development in Information
    255-260, 262-263, 268, 271,            Technology)  ... 284
    277, 281-282, 284-285, 291, 293     ESPRIT  ... 284, 289
 DOD  ... 213-214                       ETSI: European Telecommunications
 DTE  ... 262                              Standards Institute  ... 284
 DTP  ... 120, 128-129                  ETSI  ... 284-285
                                        ETS  ... 285
                                        Event Handling  ... 138
 E                                      EWOS: European Workshop for Open
                                           Systems  ... 285
 EBU  ... 284                           EWOS  ... 285, 289
 ECMA: European Computer                _e_x_e_c()  ... 67
    Manufacturers Association           External Environment Interface
     ... 275                               (EEI) Elements  ... 136
 ECMA  ... 91, 108, 213, 272, 275,      External Environment Interface
    278                                    (EEI)  ... 24
 EDIFACT  ... 115-116                      definition of  ... 7
 EDI  ... 116                           External Environment Interface
 EEI                                       Elements  ... 75
    definition of  ... 13               External Environment Interface
 EEI-API Service Relationships             Services  ... 48, 63, 89, 105,
     ... 27                                113, 126, 144, 159, 174, 180,
 EEI-API  ... 27                           213
 EEI  ... 7, 13, 20, 24-25, 27-28,      External Environment Interface
    32, 34, 43, 54, 74-76, 78, 82,          ... 20
    89-90, 97, 112-114, 127, 133-
    134, 136, 145, 154, 159, 171,


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 310                                              Alphabetic Topical Index






                                                               P1003.0/D14

 external environment                   G
    definition of  ... 8
                                        GAN  ... 90
                                        Gap Identification  ... 235
 F                                      Gaps in Available Standards
                                            ... 50, 68, 96, 109, 116, 129,
 Factors in Standards Selection            146, 166, 174, 185, 205, 214
     ... 30                             General Arrangement  ... 257
 Fault Avoidance  ... 223               General Normative Elements
 Fault Detection  ... 222                   ... 258
 Fault Diagnosis  ... 223               General Purpose POSIX SPs  ... 237
 Fault Isolation  ... 223               General Service Requirements
 Fault Management  ... 222                 Application Platform  ... 192
 Fault Recovery  ... 223                General Terms  ... 7
 FCC  ... 269                           General  ... 1
 FIFO  ... 67                           Generalized Input/Output Services
 File Modification Primitives               ... 59
     ... 60                             getconf  ... 244
 File Oriented Services  ... 60         GKS-3D  ... 151, 159, 162, 164
 File Support Services  ... 61          GKS  ... 131, 147, 151, 153, 159,
 file system  ... 67-68, 246-247           161-164, 243
 FIMS  ... 174                          GOSIP  ... 235, 283
 FIMS  ... 146, 174                     graphical user interface  ... 131
 find  ... 241                          Graphical Window System Services
 FIPS 120  ... 163                          ... 131
 FIPS 127  ... 106, 130                 Graphics Concepts  ... 155
 FIPS 151-1  ... 66                     Graphics Requirements  ... 157
 FIPS 158  ... 147                      Graphics Services  ... 149
 FIPS  ... 108, 146, 234, 243, 245,     Graphics Standards Language
    260, 278                               Bindings  ... 162
 Flagger  ... 106                       Graphics Standards  ... 161
 foreground  ... 182                    grep  ... 241
 Foreword  ... 258                      Guidance to Profile Writers
 _f_o_r_k()  ... 10, 67                         ... 230
 Form Management  ... 173               GUS  ... 289
 Formal Standards Groups  ... 267
 FORTRAN-77  ... 243
 FORTRAN  ... 47                        H
 Fortran  ... 49
 FORTRAN  ... 27, 45-48, 106, 239,      Hardware Description Language
    241                                    (VHDL VHSIC)  ... 117
 FTAM  ... 71, 81, 91, 95               hardware
 FTP  ... 91, 96                           definition of  ... 8
 FULL  ... 263                          harmonization  ... 229
 Functionality of POSIX.1 Standard      Harmonization  ... 234
     ... 67                             HCI  ... 1, 131
                                        HDLC  ... 91




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              311






 P1003.0/D14

 Heterogeneous Environment Support      IEEE P1003.6  ... 71, 213-214
    Services  ... 106                   IEEE P1003.7  ... 82
 HFS-HCI  ... 146                       IEEE P1003.8  ... 91
 High-End Realtime Applications         IEEE P1003.   ... 6
     ... 247                            IEEE P1003  ... 13
 HLHSR  ... 164                         IEEE P1076  ... 115, 117
 HSF-HCI  ... 145                       IEEE P1201.1  ... 146
 Human/Computer Interaction             IEEE P1201.2  ... 145-146
    Services API  ... 26                IEEE P1201.   ... 146
 Human/Computer Interaction             IEEE P1201  ... 168
    Services  ... 25                    IEEE P1224.1  ... 80
 Human/Computer Interface               IEEE P1224  ... 91
    definition of  ... 8                IEEE P1237  ... 91
                                        IEEE P1238.0  ... 80
                                        IEEE P1238.1  ... 81, 91, 95
 I                                      IEEE P1238  ... 91, 95
                                        IEEE POSIX.2  ... 184
 IBM  ... 290                           IEEE Std 1003.1  ... 6, 65-66
 ICL  ... 290                           IEEE Std 1003.3  ... 66
 ICS  ... 286                           IEEE-488  ... 277
 ICST  ... 278                          IEEE  ... 6, 13, 53, 145, 159,
 IEC: International                        183-184, 231, 238-243, 245,
    Electrotechnical Commission            249, 251, 253, 255, 263, 268,
     ... 272                               272, 276-278, 286, 291
 IEEE 1003.11  ... 244                  IEEE Standards Diagram  ... 277
 IEEE 1003.2  ... 244                   IGES/PDES  ... 169
 IEEE 1003.4  ... 244                   IGES  ... 115-116, 167, 243
 IEEE 1003.6  ... 245                   III  ... 36
 IEEE 802.3  ... 277                    Implementation Aspects  ... 76,
 IEEE: Institute of Electrical and         101, 123
    Electronic Engineers  ... 276       implementation defined  ... 5, 68
 IEEE P1003.10  ... 238, 291               definition of  ... 5
 IEEE P1003.11  ... 127, 129, 238,      Importance Of Profiles  ... 230
    245, 291                            Information Interchange Interface
 IEEE P1003.12  ... 71, 78, 80, 91         definition of  ... 8
 IEEE P1003.13  ... 238                 Information Interchange Services
 IEEE P1003.14  ... 238                    API  ... 26
 IEEE P1003.15  ... 184                 Information Resource Dictionary
 IEEE P1003.17  ... 80, 82, 91, 95         System (IRDS)  ... 108
 IEEE P1003.18  ... 238                 Information Services  ... 25
 IEEE P1003.1  ... 272, 291             Information System Management
 IEEE P1003.2  ... 6, 291                   ... 215
 IEEE P1003.3  ... 6, 252, 254-255,     Informative Annexes  ... 260
    278                                 informative
 IEEE P1003.4  ... 68, 250, 252,           definition of  ... 6
    291                                 Initial Graphics Exchange
 IEEE P1003.4a  ... 68                     Specification (NBSIR 86-3359)
                                            ... 116



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 312                                              Alphabetic Topical Index






                                                               P1003.0/D14

 Input Device Management  ... 140,      ISO 10148  ... 91
    173                                 ISO 10164  ... 91
 Input Model  ... 156                   ISO 10165  ... 91
 Input Primitives  ... 156              ISO 1359  ... 44
 INTAP (Interoperability Technology     ISO 1539  ... 48-49
    Association for Information         ISO 1989  ... 44, 48-49
    Processing)  ... 285                ISO 2014  ... 200
 INTAP  ... 285, 289                    ISO 2022  ... 200
 Interapplication Entity Services       ISO 3307  ... 200
     ... 144                            ISO 4031  ... 200-201
 Interapplication Software Entity       ISO 4217  ... 200-201
    Services  ... 48, 63                ISO 4873  ... 200-201, 204
 Interclient Communication  ... 139     ISO 6093  ... 200, 202
 interface                              ISO 6160  ... 48, 50
    definition of  ... 8                ISO 6373  ... 48-49
 International and National             ISO 6429  ... 200, 202
    Standards Bodies Relationship       ISO 646  ... 200, 202
     ... 266                            ISO 6522  ... 48, 50
 International and National             ISO 6936  ... 200, 202
    Standards Organizations             ISO 6937-1  ... 200, 202
     ... 267                            ISO 6937-2  ... 200, 202
 International Standards Bodies         ISO 6937  ... 202
    Overview  ... 266                   ISO 7185  ... 48-49
 International Standards  ... 200,      ISO 7350  ... 200, 202
    204                                 ISO 7498-2  ... 213
 Internationalization Standards         ISO 7498  ... 262
     ... 201                            ISO 7776  ... 91
 Internationalization  ... 185, 189     ISO 7942  ... 159, 163
 internationalization                   ISO 7-  ... 200, 202
    definition of  ... 8                ISO 803  ... 91
 interoperability                       ISO 8072  ... 91, 262
    definition of  ... 8                ISO 8208  ... 91
 Interoperable Networking Standards     ISO 8327  ... 91
     ... 96                             ISO 8348  ... 91
 Introduction  ... 228, 237, 249,       ISO 8473  ... 91
    258, 265                            ISO 8485  ... 48
 IPC  ... 37, 241                       ISO 857  ... 91
 IPI  ... 159, 165                      ISO 8587  ... 97
 IPO  ... 169                           ISO 8601  ... 200, 203
 IPS  ... 73, 80                        ISO 8602  ... 91
 IRDS  ... 106, 108                     ISO 8613  ... 91, 115, 214
 ISAM  ... 102                          ISO 8632-1  ... 159
 ISDN  ... 283                          ISO 8632  ... 115-116, 165
 ISIS  ... 117                          ISO 8649-2  ... 91
 ISO 10021  ... 91                      ISO 8650-1  ... 91
 ISO 10026  ... 91                      ISO 8650  ... 91
 ISO 10040  ... 91                      ISO 8651-1  ... 163




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              313






 P1003.0/D14

 ISO 8651-2  ... 163                    ISO/IEC 10026-1  ... 127
 ISO 8652  ... 48, 92                   ISO/IEC 8073  ... 262
 ISO 8653  ... 92                       ISO/IEC 8613  ... 213
 ISO 8802-2  ... 91                     ISO/IEC 9804  ... 110
 ISO 8802-3  ... 91                     ISO/IEC 9805  ... 110
 ISO 8802-4  ... 92                     ISO/IEC 9899  ... 48-49
 ISO 8802-5  ... 92                     ISO/IEC 9945-1  ... 2, 64-66, 68,
 ISO 8805  ... 159, 164                    239, 244, 288, 293
 ISO 8823  ... 91                       ISO/IEC 9945-2  ... 184
 ISO 8824  ... 91, 110, 117, 207        ISO/IEC 9945  ... 10
 ISO 8825  ... 91, 110, 115, 117,       ISO/IEC 9995-  ... 200
    207                                 ISO/IEC CD 9995-  ... 204
 ISO 8859-1  ... 2, 192, 205            ISO/IEC DIS 10026-1  ... 128
 ISO 8859-  ... 200, 203                ISO/IEC DIS 10026-2  ... 128
 ISO 8879  ... 115, 169                 ISO/IEC DIS 10026-3  ... 128
 ISO 8907  ... 106-107                  ISO/IEC DIS 10026  ... 130
 ISO 8-  ... 201                        ISO/IEC DIS 10367  ... 204
 ISO 9075  ... 106, 130                 ISO/IEC DIS 9804-3  ... 130
 ISO 9548  ... 91                       ISO/IEC DIS 9805-3  ... 130
 ISO 9576  ... 91                       ISO/IEC DP 10026-1  ... 119
 ISO 9579  ... 92                       ISO/IEC DP 9759  ... 106
 ISO 9592-1  ... 159                    ISP  ... 231
 ISO 9592-2  ... 159                    Issues Pertaining to Referencing
 ISO 9592  ... 159, 165                    Base Standards  ... 254
 ISO 9593-1  ... 159                    ITA  ... 202
 ISO 9593-3  ... 159                    ITU  ... 266
 ISO 9593  ... 91
 ISO 9594  ... 92
 ISO 9595  ... 92                       J
 ISO 9596  ... 91-92
 ISO 9735  ... 92, 115-116              JISC: Japanese Industrial
 ISO 9945  ... 6                           Standards Committee  ... 272
 ISO DIS 10641  ... 159                 JISC  ... 272-273
 ISO DIS 10646  ... 204                 JIS  ... 200, 204
 ISO DIS 8613  ... 206                  Job Scheduling  ... 220
 ISO DIS 9592-4  ... 159                JTC1: Joint Technical Committee 1
 ISO DIS 9636  ... 159                      ... 273
 ISO DP 10027  ... 106
 ISO DP 10303  ... 115-116
 ISO DP 8800  ... 106                   K
 ISO DP 9579-1  ... 108
 ISO DP 9579-2  ... 108                 KEYSYM  ... 167
 ISO: International Organization        KornShell  ... 25, 278, 285, 289,
    for Standardization  ... 272           293
 ISO Protocol Stack Standards
     ... 91
 ISO/CCITT X.400  ... 118, 213




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 314                                              Alphabetic Topical Index






                                                               P1003.0/D14

 L                                      MAP  ... 235, 285-286
                                        MAP/TOP User Group: (Manufacturing
 language binding  ... 8-9, 21,            Automation Protocol and
    26-27, 43, 45, 51, 95, 128,            Technical and Office Protocol)
    132, 135, 137, 150, 152-153,            ... 285
    158-159, 162-165, 215, 239,         MAP/TOP  ... 285-286, 289
    241, 244                            may
 Language Resource Management              definition of  ... 6
    Services  ... 48                    Memory Management Services  ... 62
 Language Service Reference Model       Methods for Developing Profiles
     ... 44                                 ... 235
 Language Services  ... 43              MHS  ... 118
 Language Standards  ... 49             Mid-Range Realtime Applications
 language-binding API                       ... 247
    definition of  ... 8                MIL-STD-114A  ... 91
 language-independent service           MIL-STD-1777  ... 91, 96
    specification                       MIL-STD-1778  ... 91, 96
    definition of  ... 9                MIL-STD-1780  ... 91, 96
 LAN  ... 90, 292                       MIL-STD-1781  ... 91, 96
 LANS  ... 277                          MIL-STD-1782  ... 91, 96
 LAPB  ... 91                           MIL-STD  ... 78, 96
 Layering  ... 35                       Miscellaneous Database Services
 License Services  ... 218                  ... 104
 LISP  ... 45, 47-48, 50, 164, 243      MITI  ... 273, 285
 LIS  ... 128, 162                      MIT  ... 159, 166, 168
 local adaptation                       MOSI  ... 27
    definition of  ... 9                MS-DOS  ... 205
 locale                                 Multipart POSIX SPs  ... 256
    definition of  ... 9                Multiple POSIX OSE APIs to
 _l_o_c_a_l_e()  ... 200                         Different OSI Layers  ... 80
 locale  ... 9, 67, 182, 200, 260       Multiprocessing Systems Platform
 Localization Tools Requirements           Profiles  ... 239
     ... 199
 localization
    definition of  ... 9                N
 Logical Naming Services  ... 62
 Low Cost Wide Area Networking          Naming and Directory Services
     ... 96                                 ... 60
                                        naming services
                                           logical  ... 62
 M                                      National Standards Bodies Overview
                                            ... 266
 MAC  ... 212                           National Standards  ... 204-205
 Main Elements of a Profile             Natural Language Support  ... 197,
    Definition Document  ... 233           199
 Maintainability  ... 224               NBSIR 86-3359  ... 115-116, 167
 make  ... 241                          NBSIR 86  ... 115




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              315






 P1003.0/D14

 NDL Standard Database Language         OLTP  ... 120, 127, 144, 244
     ... 107                            OMG  ... 287-288
 NDL  ... 106-108                       Online Disk Management  ... 220
 Network Application Program            Open Document Architecture
    Interface (API) Services               (ODA)/Open Document Interchange
     ... 74                                Format (ODIF)  ... 115
 Network Configuration Management       Open Issues  ... 51, 118, 148
     ... 216                            open specifications
 Network Management Forum  ... 287         definition of  ... 9
 Network Management Services            Open System Application Program
     ... 88                                Interface
 Network Services  ... 73                  definition of  ... 9
 Networking Standards  ... 92           Open System Environment (OSE)
 NIST: National Institute of               definition of  ... 9
    Standards and Technology            open system
     ... 278                               definition of  ... 9
 NIST  ... 146, 163, 243, 268, 272,     OSC  ... 64, 69
    278, 283, 286                       OSE Cross-Category Services
 NMF  ... 91, 287                           ... 50, 70, 97, 109, 117, 147,
 Node Internal Communication and           167, 175, 206, 225
    Synchronization Services            OSF: Open Software Foundation
     ... 58                                 ... 288
 Nongovernment Formal Standards         OSF/1  ... 69
    Organizations  ... 275              OSF/1  ... 69, 183, 185
 Nontechnical Security Objectives       OSF  ... 64, 69, 183, 185, 288,
     ... 211                               291
 Normative Annexes  ... 260             OSI Distributed Transaction
 Normative References  ... 2, 259          Processing (DTP)  ... 128
 normative                              OSI  ... 11, 32, 71, 73, 77-82,
    definition of  ... 6                   89, 94-96, 108, 110, 128-129,
 NOTE  ... 124                             144, 167-168, 214, 243, 245,
 NPSC: National Protocol Support           272, 274-275, 278, 283, 285-
    Center  ... 287                        287, 289
 NPSC  ... 287                          OSI Network Services Standards
 NURBS  ... 155                             ... 94
                                        OSI Reference Model  ... 77
                                        Other Issues  ... 253
 O                                      Output Model  ... 157
                                        Output Primitives  ... 155
 Object Management Group  ... 287
 ODA/ODIF  ... 115, 206
 ODA  ... 115, 206, 213                 P
 ODASYL  ... 146, 174
 ODIF  ... 115                          P1003.4  ... 68
 Office Media Management and            P.10  ... 45
    Backup/Restore  ... 219             P.5  ... 41
 OLTP Resource Management Services      Pascal  ... 47, 49-50
     ... 127



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 316                                              Alphabetic Topical Index






                                                               P1003.0/D14

 PCI  ... 91                            POSIX Open System Environment
 PCTE  ... 275, 284                        Standards  ... 29
 PEP  ... 239                           POSIX OSE Cross-Category Services
 performance evaluation                     ... 130, 185, 187
    definition of  ... 10                  definition of  ... 10
 Performance Management  ... 221        POSIX OSE Reference Model (with
 performance requirement                   Transaction Processing)
    definition of  ... 10                   ... 122
 performance                            POSIX OSE-Based Distributed
    definition of  ... 10                  Systems  ... 27
 Petrotechnical Open Software           POSIX Platform Environment Profile
    Corporation  ... 288                    ... 237
 PEX  ... 147, 159, 166-167, 243        POSIX SP Procedures and Rules
 PEX-SI  ... 166                            ... 255
 PHIGS PLUS  ... 159, 163               POSIX SP Profiling Efforts
 PHIGS  ... 131, 147, 151, 153,             ... 237
    159-163, 165-167, 243               POSIX Standardized Profile (POSIX
 PIK  ... 153, 166                         SP)
 pipe  ... 67, 157                         definition of  ... 10
 pipes  ... 67                          POSIX Standardized Profiles In-
 PL/1  ... 48, 50                          Progress  ... 237
 PL/1  ... 45, 48, 50, 106, 128,        POSIX.0
    162, 280                               definition of  ... 13
 PLP  ... 91                            POSIX.0  ... 10, 13, 253, 277
 PLUS  ... 159, 163                     POSIX.10  ... 236, 240-244
 P.O  ... 284, 286                      POSIX.11 POSIX Transaction
 portability                               Processing  ... 129
    definition of  ... 10               POSIX.11  ... 121, 128-129, 236,
 Portable Operating System                 241
    Interface (POSIX) Part 1            POSIX.13  ... 235, 241, 245-246
     ... 65                             POSIX.14  ... 236, 239-241
 POSC  ... 288-289                      POSIX.15  ... 240, 243
 POSI: Promoting Conference for OSI     POSIX.18  ... 236, 238-239
     ... 289                            POSIX.1  ... 27, 30-31, 44, 66,
 POSI  ... 283, 285, 287, 289-290          129, 145, 184, 214, 227-229,
 POSIX Network Standards Efforts           238, 240, 243-244, 246-247,
     ... 78                                250, 252, 277-278, 288, 293
 POSIX Open System Environment -        POSIX.2  ... 6, 43, 97, 145, 183-
    General Requirements  ... 16           185, 228, 239-240, 243, 252
 POSIX Open System Environment          POSIX.3  ... 6
    (POSIX OSE)                         POSIX.4  ... 129, 183, 236, 240,
    definition of  ... 10                  243, 245-247
 POSIX Open System Environment          POSIX.5  ... 241
    Profiles  ... 32                    POSIX.6  ... 241, 243
 POSIX Open System Environment          POSIX.7  ... 241, 243
    Reference Model  ... 19             POSIX.8  ... 117, 129, 243
 POSIX Open System Environment          POSIX.9  ... 241
    Services  ... 28, 39



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              317






 P1003.0/D14

 POSIX                                  Processor Configuration Management
    definition of  ... 6                    ... 216
 POSIX._n                                Profile Concepts  ... 228
    definition of  ... 13               Profile Objectives  ... 233
 POSIX-OSE  ... 17                      profile
 POSIX Database Reference Model            definition of  ... 10
     ... 101                            Profiles  ... 227
 POSIX Network Services Model           programming language API  ... 26
     ... 81                                definition of  ... 11
 POSIX Networking Reference Model       Prolog  ... 45, 48, 50
     ... 74                             PROLOG  ... 48
 POSIX Open System Environment          protocol (OSI)
     ... 15                                definition of  ... 11
 POSIX OSE Graphics Service             Public Specifications  ... 69,
    Reference Model Standards              116, 129, 166, 175, 185, 205
     ... 160                            public specifications
 POSIX OSE Graphics Service                definition of  ... 11
    Reference Model  ... 154            Purpose of Profiles  ... 231
 POSIX OSE Reference Model -            PVT  ... 163
    Distributed Systems  ... 28
 POSIX OSE Reference Model -
    Entities  ... 22                    R
 POSIX OSE Reference Model -
    Interfaces  ... 24                  RACE  ... 290
 POSIX OSE Reference Model for          RDA  ... 106, 108, 284, 290
    Command Interfaces  ... 178         Realtime Application Profiles
 POSIX OSE Reference Model  ... 20          ... 245
 POSIX OSE Transaction Processing       Realtime Files  ... 61
    Reference Model  ... 123            Reconfiguration  ... 224
 POSIX SPs In Progress  ... 238         Redirection  ... 36
 Preliminary Elements  ... 258          redirection
 Presentation Management  ... 138,         definition of  ... 11
    172                                 Reference Model Entities and
 Prevention of Data Compromise             Elements  ... 21
     ... 70                             Reference Model Interfaces  ... 24
 Prevention of Service Denial           Reference Model  ... 43, 53, 73,
     ... 71                                100, 112, 120, 133, 151, 171,
 Prevention of Unauthorized Access         177, 191, 210, 216
     ... 70                             reference model
 Primitive Attributes  ... 155             definition of  ... 11
 Principles  ... 255                    Regional Standards  ... 203, 205
 Print Output and Distribution          regular expression  ... 180
    Services  ... 218                   Related Organizations  ... 281
 process ID  ... 67                     Related Service Requirements
 Process Management Services                ... 174
     ... 56                             Related Standards  ... 51, 71, 97,
 process                                   109, 117, 130, 147, 167, 175,
    definition of  ... 10                  185, 206, 225



              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 318                                              Alphabetic Topical Index






                                                               P1003.0/D14

 Relationship Between the OSI           SC27  ... 274
    Reference Model and the POSIX       SC28  ... 274
    OSE Network Reference Model         SC29  ... 169
     ... 77                             SC2  ... 274
 Relationship of OSI and POSIX OSE      SC47B  ... 273
    Network Reference Models            SC4  ... 145-146, 169
     ... 79                             SC6  ... 274
 Relationship to Base Standards         SC7  ... 274
     ... 232                            scaleability
 Relationships Between This Guide          definition of  ... 11
    and Profiles  ... 228               SCC  ... 276
 Remote Data Access (RDA) Protocol      Scope and Number of POSIX SPs
     ... 108                                ... 254
 Requirements  ... 259                  Scope  ... 1, 43, 53, 73, 99, 111,
 Resource Management Services              120, 132, 150, 171, 177, 190,
     ... 64                                210, 215, 227, 249, 259
 RFC-1034  ... 91                       Screen Management  ... 140, 173
 RFT  ... 288                           Security Administration  ... 71
 RG1  ... 293                           Security Management  ... 225
 RIG  ... 286, 292                      Security Standards  ... 213
 Role of POSIX SPs  ... 250             Security  ... 109, 147, 175
 Routing and Relay Services  ... 90     security
 RPC Services  ... 85                      definition of  ... 11
 RPC  ... 84-85, 91, 122, 129, 243,     Selected Major Standards and
    245                                    Standards-Influencing Bodies
 RS-232  ... 91                             ... 267
 Rules for Drafting and                 Selection Precedence  ... 31
    Presentation of POSIX SPs           Server Connection Management
     ... 257                                ... 141
                                        Service Components and Interfaces
                                            ... 33
 S                                      service delivery latency
                                           definition of  ... 11
 SC11  ... 274                          service request latency
 SC13  ... 274                             definition of  ... 11
 SC14  ... 274                          Service Requirements  ... 44, 55,
 SC15  ... 274                             82, 102, 113, 124, 136, 155,
 SC17  ... 274                             172, 179, 191, 211, 216
 SC18  ... 145-146, 169, 274            Services Provided by the
 SC1  ... 274                              Application Platform at the EEI
 SC20  ... 274                              ... 90
 SC21  ... 108, 121, 128, 214, 274      session  ... 63, 91, 144, 199, 217
 SC22  ... 50, 274                      _s_e_t_l_o_c_a_l_e()  ... 67
 SC23  ... 274                          SGFS (Special Group on Functional
 SC24  ... 274                             Standardization)  ... 275
 SC25  ... 274                          SGFS  ... 231, 275
 SC26  ... 274                          SGML  ... 115, 169




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              319






 P1003.0/D14

 Shell and Utilities Standards          Standards Infrastructure
     ... 183                               Description  ... 265
 shell  ... 43, 148, 177-178, 182-      standards
    184, 239-240, 243-244                  definition of  ... 12
 should                                 Status of System Components
    definition of  ... 6                    ... 224
 SII                                    STD  ... 213-214
    definition of  ... 13               STEP  ... 115-116, 169
 SII  ... 12-13, 33-34, 122-123,        STET  ... 290
    129                                 Storage/Archiving  ... 157
 Simple Network Services  ... 85        Structure of Documentation for
 SIRS  ... 91                              POSIX SPs  ... 255
 SLA  ... 220                           Subdivision  ... 34
 SMB  ... 91                            Supercomputing  ... 242
 SMC  ... 279                           Supplementary Elements  ... 260
 SMTP  ... 91, 96                       SVID  ... 69
 SNI  ... 78, 81-82, 91, 95             SVID  ... 64, 69, 183, 185, 263,
 Software Installation and                 291, 293
    Distribution  ... 217               System Administration  ... 64
 Software Safety  ... 223               System Internal Interface (SII)
 software                                  definition of  ... 12
    definition of  ... 11               System Operator Services  ... 64
 SPAG: Standards Promotion and          System Security Services  ... 209
    Application Group  ... 289          System Services API  ... 25
 SPAG-CCT  ... 289                         definition of  ... 12
 SPAG  ... 283, 285, 287, 289-290       System Services Reference Model
 SPARC  ... 279                             ... 54
 SPC  ... 279                           System Services Standards  ... 65
 Special Rules for POSIX SPs            System Services  ... 53
     ... 251                            system services
 specification                             definition of  ... 12
    definition of  ... 11               system software
 SQL Access Group  ... 290                 definition of  ... 12
 SQL Standard Database Language         System V  ... 66, 69, 146, 185,
     ... 106, 130                          263, 291, 293
 SQL  ... 102, 106-108, 129-130,
    229, 245, 278, 284, 290
 SSP  ... 210-211                       T
 Standard for the Exchange of
    Product Model Data (STEP)           T1  ... 279
     ... 116                            T.61  ... 200, 203
 Standard Generalized Markup            TAG  ... 279
    Language (SGML)  ... 115            Targeted Realtime Application
 standardized profile                      Profiles  ... 246
    definition of  ... 12               Task Management Services  ... 57
 Standards and Specifications           TBD  ... 269, 287, 289-290, 293
    outside the POSIX OSE  ... 50       TC130  ... 169




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 320                                              Alphabetic Topical Index






                                                               P1003.0/D14

 TC159  ... 145-146                     Transaction Processing Standards
 TC184  ... 169                             ... 128
 TC22  ... 108, 275                     Transaction Processing  ... 244
 TC47B  ... 274                         transaction
 TC83  ... 274                             definition of  ... 12
 TC86  ... 275                          Types of Access Methods  ... 103
 TC97  ... 108, 273                     Types of Data Objects  ... 103
 TCOS-SEC  ... 254                      Types of Database Management
 TCOS-SSC  ... 249, 263                    Systems  ... 103
 TCP/IP  ... 73, 78, 82, 90-91,         Types of Profiles  ... 235
    95-96, 168, 243, 245
 TCP  ... 91
 Technical Normative Elements           U
     ... 259
 Technical Security Objectives          UCA  ... 283
     ... 211                            undefined  ... 257
 TELNET  ... 96                         UniForum  ... 290
 terminal  ... 12, 58, 66-67, 70,       Universe of Profiles and Standards
    91, 120, 125, 130-133, 144,             ... 250
    146, 171-172, 174-175, 182,         UNIX International/UNIX System
    221, 262, 273                          Laboratories  ... 291
 Terminology and General                UNIX  ... 47, 66, 96-97, 177,
    Requirements  ... 5                    183-185, 236, 238, 242, 263,
 Terminology  ... 5                        284, 291-292
 terms  ... 7                           Unsatisfied Service Requirements
 Test Methods  ... 3                        ... 50, 69, 117, 130, 167, 205
 TFA  ... 91                            unspecified  ... 232
 Time Services  ... 62                  UPE  ... 183
 Title  ... 258                         USA  ... 278, 283
 TM/TPRM  ... 122-124, 129              User Administration  ... 221
 TOC  ... 1, 5, 15, 39, 187, 227,       User Alliance for Open Systems
    237, 265, 295                           ... 292
 Toolkit Window Services  ... 141       User Command Interface Services
 TOP  ... 235, 286                          ... 177
 TP0  ... 91                            User Interface EEI Elements
 TP4  ... 91                                ... 75
 TPRM  ... 122, 129                     User Interface Management Systems
 TR 10000  ... 231                         (UIMS)  ... 143
 Traditional Database Model             user interface  ... 131
     ... 100                            User Preferences Management
 transaction application program            ... 140
    definition of  ... 12               USI-P001  ... 238
 Transaction Manager API  ... 121       USL  ... 291
 Transaction Processing Services        USTAR  ... 67
     ... 119                            UUCP  ... 90, 96-97
 Transaction Processing Standards
    Language Bindings  ... 128




              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 Alphabetic Topical Index                                              321






 P1003.0/D14

 V                                      X/PEX  ... 153
                                        XPG3  ... 69
 Validation  ... 234                    XPG3  ... 69, 175, 183, 185
 validation
    definition of  ... 12
 VDI  ... 165
 VHDL  ... 115, 117
 VHSIC  ... 115, 117
 VMUIF  ... 146


 W

 _w_a_i_t()  ... 67
 WAN  ... 90
 WG15  ... 274
 WG19  ... 145-146
 WG1  ... 214
 WG21  ... 50
 WG3  ... 108
 WG5  ... 128, 145-146
 Window Management  ... 137
 Windowing Reference Model  ... 133
 Windowing Resource Management
    Services  ... 144
 Windowing Standards  ... 145
 WINDOWS-3  ... 205


 X

 X Window System  ... 146
 X.12  ... 115-116
 X.212  ... 262
 X.214  ... 91
 X.224  ... 91
 X.25  ... 89, 91, 262
 X3  ... 279
 X.400 API Association  ... 292
 X.400  ... 80, 91, 95-96, 292
 X.500  ... 82, 91, 95
 X.509  ... 213
 XIII  ... 284
 XLIB  ... 168
 X/Open TP  ... 129
 X/Open  ... 293
 X/Open  ... 69, 91, 95, 129-130,
    175, 183, 185, 209, 245, 263,
    291-293


              Copyright (c) 1991 IEEE.  All rights reserved.
      This is an unapproved IEEE Standards Draft, subject to change.




 322                                              Alphabetic Topical Index






                                                               P1003.0/D14

                              Acknowledgments

 We wish to thank the following organizations for donating significant
 computer, printing, and editing resources to the production of this
 standard:  the X/Open Company, Ltd.

 Also we wish to thank the organizations employing the members of the
 Working Group and the Balloting Group for both covering the expenses
 related to attending and participating in meetings, and donating the time
 required both in and out of meetings for this effort.

 _E_d_i_t_o_r'_s _N_o_t_e:  _T_h_i_s _l_i_s_t _s_h_o_u_l_d _b_e _t_h_e _u_n_i_o_n _o_f _t_h_e _c_o_m_p_a_n_i_e_s _s_p_o_n_s_o_r_i_n_g
 _W_o_r_k_i_n_g _G_r_o_u_p _a_t_t_e_n_d_e_e_s _a_n_d _B_a_l_l_o_t_i_n_g _G_r_o_u_p _m_e_m_b_e_r_s.  _I_t _w_i_l_l _a_p_p_e_a_r
 _a_f_t_e_r _b_a_l_l_o_t_i_n_g _b_e_g_i_n_s.

                    <_t_o _b_e _p_r_o_v_i_d_e_d>   <_t_o _b_e _p_r_o_v_i_d_e_d>

 In the preceding list, the organizations marked with an asterisk (*) have
 hosted 1003 Working Group meetings since the group's inception in 1985,
 providing useful logistical support for the ongoing work of the
 committees.




































                                                                       323